Title: GitHub Actions ಚೇತರಿಸಿಕೊಂಡಿದೆ ಆದರೆ ಮ್ಯಾನುಯಲ್ ಸರಿಪಡಿಸುವಿಕೆಗಳು ಅಗತ್ಯವಾಗಿವೆ
GitHub Actions ಆಗಸ್ಟ್ 7 ರಂದು 02:04 UTC ಸಮಯಕ್ಕೆ ಮತ್ತೆ ಕಾರ್ಯನಿರ್ವಹಿಸಲು ಪ್ರಾರಂಭಿಸಿತು. ಈ ಸೇವೆಯ ವ್ಯತ್ಯಯವು (outage) ನಡೆಯದೆ ಉಳಿದ push ಮತ್ತು pull-request ಇವೆಂಟ್ಗಳ (events) ಸಾಲನ್ನು ಬಿಟ್ಟುಹೋಗಿದೆ, ಆದ್ದರಿಂದ ಡೆವಲಪರ್ಗಳು ಆ ರನ್ಗಳನ್ನು (runs) ಕೈಯಾರೆ ಮರುಪ್ರದರ್ಶಿಸಬೇಕಾಗುತ್ತದೆ.
ಸ್ಟೇಟಸ್ ಪೇಜ್ ಈಗ ಹಸಿರು ಬಣ್ಣದಲ್ಲಿ ತೋರಿಸುತ್ತಿದೆ, ಆದರೆ ಸೇವೆಯ ವ್ಯತ್ಯಯದ ಸಮಯದಲ್ಲಿ ಪ್ರಾರಂಭವಾಗಬೇಕಿದ್ದ ಯಾವುದೇ ವರ್ಕ್ಫ್ಲೋಗಳು (workflows) ಸ್ಥಗಿತಗೊಂಡಿದ್ದವು. GitHub ತಪ್ಪಿದ ಟ್ರಿಗ್ಗರ್ಗಳನ್ನು (triggers) ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಮರುಪ್ರದರ್ಶಿಸಲು ಸಾಧ್ಯವಾಗದ ಕಾರಣ, ತಂಡಗಳು ಹೊಸ ಕಮಿಟ್ ಅನ್ನು ಪುಶ್ ಮಾಡಬೇಕು, pull request ಅನ್ನು ಅಪ್ಡೇಟ್ ಮಾಡಬೇಕು ಅಥವಾ UI ನಲ್ಲಿರುವ Re-run jobs ಬಟನ್ ಅನ್ನು ಕ್ಲಿಕ್ ಮಾಡಬೇಕು. ಓಪನ್-ಸೋರ್ಸ್ Actions Runner Controller ಬಳಸುವ ಬಳಕೆದಾರರು, ರನ್ನರ್ ಪಾಡ್ಗಳು (runner pods) ಸುಮ್ಮನೆ ನಿಂತಿಲ್ಲ ಎಂಬುದನ್ನು ಸಹ ಪರಿಶೀಲಿಸಬೇಕಾಗುತ್ತದೆ.
ಏನಾಯಿತು ಮತ್ತು ಇದು ಏಕೆ ಮುಖ್ಯ
GitHub Actions ಲಕ್ಷಾಂತರ ರೆಪೊಸಿಟರಿಗಳ (repos) CI ಪೈಪ್ಲೈನ್ಗಳನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ. ಇದು ಸ್ಥಗಿತಗೊಂಡಾಗ, ಕೋಡ್ ಬದಲಾವಣೆಗಳು ನಿಂತುಹೋಗುತ್ತವೆ, ಟೆಸ್ಟ್ ಸೂಟ್ಗಳು (test suites) ನಡೆಯುವುದಿಲ್ಲ ಮತ್ತು ಡಿಪ್ಲಾಯ್ಮೆಂಟ್ಗಳು ವಿಳಂಬವಾಗುತ್ತವೆ. ಆಗಸ್ಟ್ 7 ರಂದು, ಸೇವೆವು push ಇವೆಂಟ್ಗಳು (ಹೊಸ ಕಮಿಟ್ಗಳು) ಮತ್ತು pull-request ಇವೆಂಟ್ಗಳು (ರಿವ್ಯೂ ಅಪ್ಡೇಟ್ಗಳು) ಎರಡನ್ನೂ ಪ್ರೊಸೆಸ್ ಮಾಡುವುದನ್ನು ನಿಲ್ಲಿಸಿತು, ಇವು ಅತ್ಯಂತ ಸಾಮಾನ್ಯವಾದ ಎರಡು CI ಟ್ರಿಗ್ಗರ್ಗಳಾಗಿವೆ.
ನಿಮ್ಮ ಪೈಪ್ಲೈನ್ಗಳನ್ನು ಹೇಗೆ ಚೇತರಿಸಿಕೊಳ್ಳುವುದು
- ಹೊಸ ಕಮಿಟ್ ಅನ್ನು ಪುಶ್ ಮಾಡಿ – ಬ್ರಾಂಚ್ನಲ್ಲಿ ಮಾಡುವ ಯಾವುದೇ ಬದಲಾವಣೆಯು ಪುಶ್ ಟ್ರಿಗ್ಗರ್ ಅನ್ನು ಮತ್ತೆ ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತದೆ.
- Pull request ಅನ್ನು ಅಪ್ಡೇಟ್ ಮಾಡಿ – PR ವರ್ಕ್ಫ್ಲೋವನ್ನು ಮರುಪ್ರದರ್ಶಿಸಲು ಕಾಮೆಂಟ್ ಸೇರಿಸಿ, ಶೀರ್ಷಿಕೆಯನ್ನು ಬದಲಾಯಿಸಿ ಅಥವಾ ಹೆಚ್ಚಿನ ಕಮಿಟ್ಗಳನ್ನು ಪುಶ್ ಮಾಡಿ.
- ವರ್ಕ್ಫ್ಲೋ ಅನ್ನು ಮ್ಯಾನುಯಲ್ ಆಗಿ ಮರುಪ್ರದರ್ಶಿಸಿ – Actions UI ಈಗ ಪ್ರತಿ ವಿಫಲವಾದ ರನ್ಗಾಗಿ “Re-run jobs” ಬಟನ್ ಅನ್ನು ತೋರಿಸುತ್ತದೆ.
ನೀವು Actions Runner Controller ಮೂಲಕ ಸೆಲ್ಫ್-ಹೋಸ್ಟೆಡ್ ರನ್ನರ್ಗಳನ್ನು (self-hosted runners) ಬಳಸುತ್ತಿದ್ದರೆ, ರನ್ನರ್ ಪಾಡ್ಗಳನ್ನು ಪರಿಶೀಲಿಸಿ. ಸೇವೆ ಮರುಸ್ಥಾಪನೆಯಾದ ನಂತರ ಕೆಲವು ಪಾಡ್ಗಳು ಸುಮ್ಮನೆ ನಿಂತಿರಬಹುದು; ಅವುಗಳನ್ನು ಮರುಪ್ರಾರಂಭಿಸಿ (restart) ಅಥವಾ ಮರು-ನಿಯೋಜಿಸಿ (redeploy).
ತಂಡಗಳಿಗೆ ಎದುರಾಗುವ ಪರಿಣಾಮಗಳು
- ಉತ್ಪಾದಕತೆಯ ನಷ್ಟ – ಸಾಮಾನ್ಯವಾಗಿ ನಿಮಿಷಗಳಲ್ಲಿ ಬರುವ ಫೀಡ್ಬ್ಯಾಕ್ಗಾಗಿ ಡೆವಲಪರ್ಗಳು ಕಾಯಬೇಕಾಗುತ್ತದೆ.
- ಬಿಡುಗಡೆಯ ವಿಳಂಬ – ರಿಲೀಸ್ ಅನ್ನು ನಿಯಂತ್ರಿಸುವ ಯಾವುದೇ ಪೈಪ್ಲೈನ್ ಶಿಪ್ಪಿಂಗ್ ದಿನಾಂಕಗಳನ್ನು ಮುಂದೂಡಬಹುದು.
- ಕಾರ್ಯಾಚರಣೆಯ ಹೊರೆ (Operational overhead) – ತಂಡಗಳು ಇತ್ತೀಚಿನ ರನ್ಗಳನ್ನು ಆಡಿಟ್ ಮಾಡಬೇಕು, ಲೋಪದೋಷಗಳನ್ನು ಪತ್ತೆಹಚ್ಚಬೇಕು ಮತ್ತು ಮೇಲಿನ ಮ್ಯಾನುಯಲ್ ಹಂತಗಳನ್ನು ನಿರ್ವಹಿಸಬೇಕು, ಇದರಿಂದ ಫೀಚರ್ ಕೆಲಸಕ್ಕಾಗಿ ಮೀಸಲಿಟ್ಟ ಸಮಯ ವ್ಯರ್ಥವಾಗುತ್ತದೆ.
ಸಾರಾಂಶ: ಸೇವೆಯ ವ್ಯತ್ಯಯವು ಪರಿಪೂರ್ಣವಾದ CI ಸೇವೆಗಳು ಕೂಡ ಕೆಲಸಗಳನ್ನು ಕಳೆದುಕೊಳ್ಳಬಹುದು ಮತ್ತು ಸ್ವಯಂಚಾಲಿತ ಮರುಪ್ರದರ್ಶನವು ಖಚಿತವಾಗಿರುವುದಿಲ್ಲ ಎಂಬುದನ್ನು ತೋರಿಸುತ್ತದೆ. ನಿಮ್ಮ ಇನ್ಸಿಡೆಂಟ್-ರಿಸ್ಪಾನ್ಸ್ ಪ್ಲೇಬುಕ್ಗಳಲ್ಲಿ (incident-response playbooks) ಮ್ಯಾನುಯಲ್ ಚೇತರಿಸಿಕೊಳ್ಳುವ ಹಂತಗಳನ್ನು ಸೇರಿಸಿ ಮತ್ತು ಹೆಚ್ಚು ಸ್ಥಿತಿಸ್ಥಾಪಕತ್ವದ (resilient) ಇವೆಂಟ್ ಹ್ಯಾಂಡ್ಲಿಂಗ್ ಕಡೆಗೆ GitHub ಮಾಡುವ ಮುಂದಿನ ಕ್ರಮಗಳನ್ನು ಗಮನಿಸಿ.