ನಿಮ್ಮ GitHub Actions CI ಏಕೆ ನಿಧಾನವಾಗಿದೆ (ಮತ್ತು ಅದನ್ನು ಹೇಗೆ ವೇಗಗೊಳಿಸುವುದು)

ಯಾರೂ ಗಮನಿಸದ ಸಮಸ್ಯೆ

ವರ್ಕ್‌ಫ್ಲೋ ವಿಫಲವಾದಾಗ GitHub ನಿಮಗೆ ಇಮೇಲ್ ಕಳುಹಿಸುತ್ತದೆ. ಆದರೆ ನಿಮ್ಮ CI ತೆಗೆದುಕೊಳ್ಳಬೇಕಾದ ಸಮಯಕ್ಕಿಂತ ಎರಡರಷ್ಟು ಸಮಯ ತಗೆದುಕೊಂಡರೆ? ನಿಮಗೆ ಯಾವುದೇ ಸೂಚನೆ ಸಿಗುವುದಿಲ್ಲ. ಪ್ರತಿಯೊಂದು pull request ಮತ್ತು ಕಮಿಟ್‌ನಲ್ಲಿ ರನ್ ಆಗುವ ನಿಧಾನಗತಿಯ ಬಿಲ್ಡ್, ಒಂದೇ ಡಿಪೆಂಡೆನ್ಸಿಗಳನ್ನು ಪದೇ ಪದೇ ಕಂಪೈಲ್ ಮಾಡುವುದು—ಇದು ನಿಮ್ಮ ಕಣ್ಣೆದುರೇ ಅಡಗಿರುವ ವ್ಯರ್ಥ ಪ್ರಕ್ರಿಯೆಯಾಗಿದೆ.

ಜೂನ್ 30, 2026 ರ ಹೊತ್ತಿಗೆ, CI ಕಾರ್ಯಕ್ಷಮತೆ ಹಿಂದೆಂದಿಗಿಂತಲೂ ಹೆಚ್ಚು ಮುಖ್ಯವಾಗಿದೆ. ಡೆವಲಪ್‌ಮೆಂಟ್ ತಂಡಗಳು ದೊಡ್ಡದಾಗಿವೆ, ಡೆಪ್ಲಾಯ್‌ಮೆಂಟ್‌ಗಳು ವೇಗವಾಗಿ ನಡೆಯುತ್ತವೆ, ಮತ್ತು ನಿಧಾನಗತಿಯ ಫೀಡ್‌ಬ್ಯಾಕ್ ಲೂಪ್‌ಗಳ ವೆಚ್ಚವು ಇಡೀ ತಂಡದಾದ್ಯಂತ ಹೆಚ್ಚಾಗುತ್ತದೆ. ನಿಮ್ಮ CI 5 ನಿಮಿಷಗಳ ಬದಲಿಗೆ 15 ನಿಮಿಷಗಳನ್ನು ತೆಗೆದುಕೊಂಡರೆ, ಮತ್ತು ನಿಮ್ಮ ತಂಡವು ವಾರಕ್ಕೆ 40 PRಗಳನ್ನು ಓಪನ್ ಮಾಡಿದರೆ, ನೀವು ಯಂತ್ರಗಳಿಗಾಗಿ ಕಾಯುತ್ತಾ ವಾರಕ್ಕೆ 8 ಗಂಟೆಗಳನ್ನು ಒಟ್ಟಾರೆಯಾಗಿ ವ್ಯರ್ಥ ಮಾಡುತ್ತಿದ್ದೀರಿ. ಇದು ಒಬ್ಬ ವ್ಯಕ್ತಿಯ ಪೂರ್ಣ ಕೆಲಸದ ಸಮಯಕ್ಕೆ ಸಮನಾಗಿರುತ್ತದೆ. ಆದಾಗ್ಯೂ ಹೆಚ್ಚಿನ ತಂಡಗಳು ಈ ಸಮಸ್ಯೆಯ ಬಗ್ಗೆ ಎಚ್ಚರಿಸುವ ಡ್ಯಾಶ್‌ಬೋರ್ಡ್ ಅನ್ನು ಎಂದಿಗೂ ನೋಡುವುದಿಲ್ಲ.

ಇದು ಏಕೆ ಸಂಭವಿಸುತ್ತದೆ

GitHub Actions ಹೊಂದಿಸುವುದು ಸರಳವಾಗಿದೆ, ಆದ್ದರಿಂದಲೇ ಅವು ಎಲ್ಲೆಡೆ ಜನಪ್ರಿಯವಾಗಿವೆ. ಆದರೆ ಆ ಸರಳತೆಯ ಕಾರಣದಿಂದಾಗಿ ಸೂಕ್ತವಾದ ಡಿಫಾಲ್ಟ್‌ಗಳು ಹೆಚ್ಚಾಗಿ ಕಾರ್ಯಕ್ಷಮತೆಯ ಕುಸಿತಗಳನ್ನು ಮರೆಮಾಡುತ್ತವೆ. ನೀವು ವರ್ಕ್‌ಫ್ಲೋ ರಚಿಸುತ್ತೀರಿ, ಅದು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಮತ್ತು ಯಾವುದಾದರೂ ಗಂಭೀರವಾಗಿ ವಿಫಲವಾಗದ ಹೊರತು, ನೀವು ಅದರ ಬಗ್ಗೆ ಆಲೋಚಿಸುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತೀರಿ. ಈ ಮಧ್ಯೆ, ವರ್ಕ್‌ಫ್ಲೋ ಅನಗತ್ಯ ಕೆಲಸವನ್ನು ಮಾಡುತ್ತಿರಬಹುದು: ಪ್ರತಿ ರನ್‌ನಲ್ಲೂ ಪ್ಯಾಕೇಜ್‌ಗಳನ್ನು ಮರು-ಇನ್‌ಸ್ಟಾಲ್ ಮಾಡುವುದು, ಬೃಹತ್ ಕ್ಯಾಶ್ ಆರ್ಟಿಫ್ಯಾಕ್ಟ್‌ಗಳನ್ನು ಅಪ್‌ಲೋಡ್ ಮಾಡುವುದು, ವರ್ಕ್‌ಫ್ಲೋ ಮ್ಯಾಟ್ರಿಕ್ಸ್‌ನಲ್ಲಿನ ಟೈಪೋ ಕಾರಣದಿಂದ ಪರೀಕ್ಷೆಗಳನ್ನು ಎರಡೆರಡು ಬಾರಿ ರನ್ ಮಾಡುವುದು, ಅಥವಾ ಬೂಟ್ ಆಗಲು ಹೆಚ್ಚಿನ ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುವ ಹಳೆಯ ಇಮೇಜ್‌ಗಳನ್ನು ಬಳಸುವುದು.

ಸಾಮಾನ್ಯ ಕಾರಣಗಳನ್ನು ಕಂಡುಹಿಡಿಯುವುದು ಮತ್ತು ಸರಿಪಡಿಸುವುದು ಸುಲಭ. ಅವುಗಳನ್ನು ವಿವರವಾಗಿ ನೋಡೋಣ.

ಸಾಮಾನ್ಯ ಕಾರಣಗಳು

ಪ್ರತಿ ಬಾರಿಯೂ ಡಿಪೆಂಡೆನ್ಸಿಗಳನ್ನು ಮರುನಿರ್ಮಾಣ ಮಾಡುವುದು

ನಿಮ್ಮ ಡಿಪೆಂಡೆನ್ಸಿಗಳನ್ನು ಕ್ಯಾಶ್ ಮಾಡದಿರುವುದು ಅತ್ಯಂತ ಸಾಮಾನ್ಯ ತಪ್ಪುಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ. ನಿಮ್ಮ ವರ್ಕ್‌ಫ್ಲೋ ಪ್ರತಿ ರನ್‌ನಲ್ಲೂ ಒಂದೇ ರೀತಿಯ npm ಪ್ಯಾಕೇಜ್‌ಗಳು, Go ಮಾಡ್ಯೂಲ್‌ಗಳು ಅಥವಾ Python ಲೈಬ್ರರಿಗಳನ್ನು ಇನ್‌ಸ್ಟಾಲ್ ಮಾಡುತ್ತಿದ್ದರೆ, ನೀವು ಪ್ರತಿದಿನ ಅದೇ ಫೈಲ್‌ಗಳಿಗಾಗಿ ಇಂಟರ್ನೆಟ್, ಅನ್‌ಪ್ಯಾಕಿಂಗ್ ಮತ್ತು ವ್ಯಾಲಿಡೇಷನ್ ವೆಚ್ಚವನ್ನು ಪದೇ ಪದೇ ಪಾವತಿಸುತ್ತಿದ್ದೀರಿ.

ಹೆಚ್ಚಿನ ಭಾಷೆಗಳು ಅಂತರ್ನಿರ್ಮಿತ ಕ್ಯಾಶಿಂಗ್ ತಂತ್ರವನ್ನು ಹೊಂದಿವೆ. Node.js ಗಾಗಿ, GitHub Actions ಅನ್ನು ಶೇಖರಿಸುವ ಕ್ಯಾಶ್ ಆಕ್ಷನ್ ಅನ್ನು ಒದಗಿಸುತ್ತದೆ node_modules ಅಥವಾ ರನ್‌ಗಳ ನಡುವೆ ನಿಮ್ಮ lock ಫೈಲ್. Python ಗಾಗಿ, ನೀವು pip wheels ಅನ್ನು ಕ್ಯಾಶ್ ಮಾಡಬಹುದು. Java Maven ಮತ್ತು Gradle ಕ್ಯಾಶ್‌ಗಳನ್ನು ಹೊಂದಿದೆ. ನೀವು ಅವುಗಳನ್ನು ಬಳಸದಿದ್ದರೆ, ನಿಮ್ಮ CI ಅನಗತ್ಯ ಕೆಲಸವನ್ನು ಮಾಡುತ್ತಿದೆ.

ನಿಧಾನಗತಿಯ ಅಥವಾ ದೊಡ್ಡ ಪ್ರಮಾಣದ ಇಮೇಜ್‌ಗಳು

GitHub Actions ವರ್ಕ್‌ಫ್ಲೋಗಳು ಕಂಟೈನರ್‌ಗಳಲ್ಲಿ ರನ್ ಆಗುತ್ತವೆ. ನೀವು ಆಯ್ಕೆ ಮಾಡುವ ಇಮೇಜ್ ಪ್ರತಿ ರನ್ ಬೂಟ್ ಆಗಲು ಎಷ್ಟು ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ ಎಂಬುದಕ್ಕೆ ಆಧಾರವಾಗಿರುತ್ತದೆ. ಹಳೆಯ ಅಥವಾ ಅನಗತ್ಯವಾಗಿ ದೊಡ್ಡದಾದ ಬೇಸ್ ಇಮೇಜ್ (ನಿಮಗೆ ಅಗತ್ಯವಿಲ್ಲದ ಬಿಲ್ಡ್ ಟೂಲ್‌ಗಳನ್ನು ಹೊಂದಿರುವ ಪೂರ್ಣ Ubuntu ನಂತಹ) ಬಳಸುವುದು ಪ್ರತಿಯೊಂದು ರನ್‌ನಲ್ಲೂ ನಿಮಿಷಗಳಷ್ಟು ಸಮಯ ವ್ಯರ್ಥ ಮಾಡುತ್ತದೆ.

ಸಾಧ್ಯವಾದಾಗ ಕನಿಷ್ಠ (minimal) ಇಮೇಜ್‌ಗಳಿಗೆ ಬದಲಾಯಿಸಿ. ನಿಮಗೆ ನಿರ್ದಿಷ್ಟ ಟೂಲ್‌ಗಳು ಬೇಕಾಗಿದ್ದರೆ, ಒಮ್ಮೆ ಕಸ್ಟಮ್ Docker ಇಮೇಜ್ ಬಿಲ್ಡ್ ಮಾಡಿ, ಅದನ್ನು GitHub Container Registry ನಂತಹ ರಿಜಿಸ್ಟ್ರಿಗೆ ಪುಶ್ ಮಾಡಿ ಮತ್ತು ಅದನ್ನು ಮರುಬಳಕೆ ಮಾಡಿ. ಮೊದಲ ರನ್ ಇಮೇಜ್ ಬಿಲ್ಡ್ ಮಾಡಲು ಹೆಚ್ಚು ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ, ಆದರೆ ನಂತರದ ರನ್‌ಗಳು ಅದನ್ನು ತಕ್ಷಣವೇ ಪುಲ್ ಮಾಡುತ್ತವೆ.

ಆಕಸ್ಮಿಕವಾಗಿ ಜಾಬ್‌ಗಳನ್ನು ಎರಡೆರಡು ಬಾರಿ ರನ್ ಮಾಡುವುದು

ವರ್ಕ್‌ಫ್ಲೋ ಮ್ಯಾಟ್ರಿಕ್ಸ್‌ಗಳು ಶಕ್ತಿಯುತವಾಗಿವೆ ಆದರೆ ತಪ್ಪಾಗಿ ಕಾನ್ಫಿಗರ್ ಮಾಡುವುದು ಸುಲಭ. ವಿವಿಧ Node ಆವೃತ್ತಿಗಳು ಅಥವಾ ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್‌ಗಳಿಗಾಗಿ ಮ್ಯಾಟ್ರಿಕ್ಸ್ ಅನ್ನು ಹೊಂದಿಸುವುದು, ನಂತರ ಅದನ್ನು ಒಮ್ಮೆ ಮಾತ್ರ ರನ್ ಮಾಡಬೇಕಾಗಿತ್ತು ಎಂದು ತಿಳಿದುಕೊಳ್ಳುವುದು ಸಾಮಾನ್ಯ ತಪ್ಪಾಗಿದೆ. ಪ್ರತಿಯೊಂದು ನಕಲಿ ರನ್ CPU, ಸ್ಟೋರೇಜ್ ಮತ್ತು ಸಮಯವನ್ನು ವ್ಯರ್ಥ ಮಾಡುತ್ತದೆ.

ನಿಮ್ಮ ವರ್ಕ್‌ಫ್ಲೋ YAML ಅನ್ನು ಪರಿಶೀಲಿಸಿ. ಅನಗತ್ಯವಾಗಿ ಕೆಲಸವನ್ನು ನಕಲು ಮಾಡುತ್ತಿರುವ ಮ್ಯಾಟ್ರಿಕ್ಸ್ ಕಂಡುಬಂದರೆ, ಅದನ್ನು ಫ್ಲ್ಯಾಟ್ ಮಾಡಿ ಅಥವಾ ಕೆಲವು ಬ್ರಾಂಚ್‌ಗಳಲ್ಲಿ ಮಾತ್ರ ರನ್ ಆಗುವಂತೆ ಷರತ್ತನ್ನು ಸೇರಿಸಿ.

ದೊಡ್ಡ ಅಥವಾ ಅನಗತ್ಯ ಆರ್ಟಿಫ್ಯಾಕ್ಟ್‌ಗಳು

ನಿಮ್ಮ ವರ್ಕ್‌ಫ್ಲೋ ಪ್ರತಿ ರನ್ ನಂತರ ದೊಡ್ಡ ಬಿಲ್ಡ್ ಆರ್ಟಿಫ್ಯಾಕ್ಟ್‌ಗಳು ಅಥವಾ ಲಾಗ್‌ಗಳನ್ನು ಅಪ್‌ಲೋಡ್ ಮಾಡಿದರೆ, GitHub ಅವುಗಳನ್ನು ಸಂಗ್ರಹಿಸಲು ಮತ್ತು ಕಂಪ್ರೆಸ್ ಮಾಡಲು ಸಮಯವನ್ನು ವಿನಿಯೋಗಿಸುತ್ತದೆ. ನೀವು ಮುಂದೆ ಆ ಆರ್ಟಿಫ್ಯಾಕ್ಟ್‌ಗಳನ್ನು ಬಳಸದಿದ್ದರೆ, ಅವು ಸಂಪೂರ್ಣವಾಗಿ ವ್ಯರ್ಥ.

ನೀವು ಏನನ್ನು ಅಪ್‌ಲೋಡ್ ಮಾಡುತ್ತೀರಿ ಎಂಬುದರ ಬಗ್ಗೆ ನಿರ್ದಿಷ್ಟವಾಗಿರಿ. ನಿಮಗೆ ಇಡೀ ಬಿಲ್ಡ್ ಡೈರೆಕ್ಟರಿ ಬೇಕೇ ಅಥವಾ ಅಂತಿಮ ಬೈನರಿ ಮಾತ್ರವೇ? ನಿಮಗೆ ಯಶಸ್ವಿ ರನ್‌ಗಳ ಲಾಗ್‌ಗಳು ಬೇಕೇ ಅಥವಾ ವಿಫಲವಾದಾಗ ಮಾತ್ರವೇ? ಹಳೆಯ ಆರ್ಟಿಫ್ಯಾಕ್ಟ್‌ಗಳು ಸಂಗ್ರಹವಾಗದಂತೆ retention ಪಾಲಿಸಿಯನ್ನು ಹೊಂದಿಸಿ.

ಪ್ಯಾರಲಲ್ ಆಗಿ ರನ್ ಆಗಬಹುದಾದ ಸೀರಿಯಲ್ ಹಂತಗಳು

ನಿಮ್ಮ ವರ್ಕ್‌ಫ್ಲೋ ಸರಣಿಯಲ್ಲಿ ಅನುಕ್ರಮವಾಗಿ lint, ಪರೀಕ್ಷೆಗಳು ಮತ್ತು ಬಿಲ್ಡ್ ರನ್ ಮಾಡಿದರೆ, ನೀವು ಕೆಲವು ಸಮಯ ಮಾತ್ರ ಒಂದೇ CPU ಕೋರ್ ಅನ್ನು ಬಳಸುತ್ತಿದ್ದೀರಿ. GitHub Actions ಡಿಫಾಲ್ಟ್ ಆಗಿ ಪ್ಯಾರಲಲ್ ಆಗಿ ಹಲವು ಜಾಬ್‌ಗಳನ್ನು ರನ್ ಮಾಡಬಹುದು. ಸ್ವತಂತ್ರ ಹಂತಗಳಿದ್ದರೆ, ಅವುಗಳನ್ನು ಪ್ರತ್ಯೇಕ ಜಾಬ್‌ಗಳಾಗಿ ವಿಭಜಿಸಿ.

ಒಂದು ಸರಳ ಉದಾಹರಣೆ: linting ವೇಗವಾಗಿದೆ ಮತ್ತು ಅದಕ್ಕೆ ಪೂರ್ಣ ಬಿಲ್ಡ್ ಅಗತ್ಯವಿಲ್ಲ. ಅದನ್ನು ಅದರದ್ದೇ ಆದ ಜಾಬ್ ಆಗಿ ರನ್ ಮಾಡಿ. ಅದು ವಿಫಲವಾದರೆ, ಪರೀಕ್ಷೆಗಳಿಗಾಗಿ ಕಾಯದೆ ನಿಮಗೆ ತಕ್ಷಣ ತಿಳಿಯುತ್ತದೆ. ಅದು ಪಾಸಾದರೆ, ಪರೀಕ್ಷೆಗಳು ಮತ್ತು ಬಿಲ್ಡ್ ಒಂದೇ ಸಮಯದಲ್ಲಿ ರನ್ ಆಗುತ್ತವೆ.

ನಿಧಾನಗತಿಯನ್ನು ಅಳೆಯುವುದು ಹೇಗೆ

ನೀವು ಆಪ್ಟಿಮೈಸ್ ಮಾಡುವ ಮೊದಲು, ನಿಮಗೊಂದು ಬೇಸ್‌ಲೈನ್ ಅಗತ್ಯವಿದೆ. GitHub Actions ಟ್ಯಾಬ್‌ನಲ್ಲಿ ವರ್ಕ್‌ಫ್ಲೋ ಟೈಮ್‌ಲೈನ್ ಅನ್ನು ಒದಗಿಸುತ್ತದೆ. ಇತ್ತೀಚಿನ ರನ್ ತೆರೆಯಿರಿ, ಮತ್ತು ಪ್ರತಿಯೊಂದು ಜಾಬ್ ಮತ್ತು ಹಂತದ ಸಮಯವನ್ನು ಗಮನಿಸಿ. ಇರಬೇಕಾದುದಕ್ಕಿಂತ ಹೆಚ್ಚು ನಿಧಾನವಾಗಿರುವ ಕನಿಷ್ಠ ಒಂದು ಹಂತವನ್ನು ನೀವು ಗುರುತಿಸುತ್ತೀರಿ.

ಸಂಖ್ಯೆಗಳನ್ನು ಬರೆದಿಟ್ಟುಕೊಳ್ಳಿ. ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡಿದ ನಂತರ, ಹಿಂತಿರುಗಿ ಬಂದು ಹೋಲಿಸಿ. "CI 12 ನಿಮಿಷಗಳಿಂದ 5 ನಿಮಿಷಗಳಿಗೆ ಕಡಿಮೆಯಾಗಿದೆ" ಎಂದು ನೋಡುವುದು ತೃಪ್ತಿಕರವಾಗಿರುತ್ತದೆ ಮತ್ತು ಸರಿಪಡಿಸುವಿಕೆ ಕಾರ್ಯನಿರ್ವಹಿಸಿದೆ ಎಂಬುದನ್ನು ನಿರೂಪಿಸುತ್ತದೆ.

ಹಂತ-ಹಂತದ ಆಪ್ಟಿಮೈಸೇಶನ್ ಪರಿಶೀಲನಾಪಟ್ಟಿ

ಹಂತ 1: ಡಿಪೆಂಡೆನ್ಸಿ ಕ್ಯಾಶಿಂಗ್ ಸಕ್ರಿಯಗೊಳಿಸಿ

ನಿಮ್ಮ ಭಾಷೆಗೆ ಕ್ಯಾಶಿಂಗ್ ಹಂತವನ್ನು ಸೇರಿಸಿ. Node.js ಗಾಗಿ, ಇದನ್ನು ನಿಮ್ಮ ವರ್ಕ್‌ಫ್ಲೋಗೆ ಸೇರಿಸಿ:

- uses: actions/setup-node@v4
  with:
    node-version: '20'
    cache: 'npm'

ಈ cache: 'npm' ಲೈನ್ ನಿಮ್ಮ node_modules ಅನ್ನು ರನ್‌ಗಳ ನಡುವೆ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಉಳಿಸಲು ಮತ್ತು ಮರುಸ್ಥಾಪಿಸಲು GitHub ಗೆ ಸೂಚಿಸುತ್ತದೆ. ಇತರ ಭಾಷೆಗಳು ಸಹ ಇದೇ ರೀತಿಯ ಆಯ್ಕೆಗಳನ್ನು ಹೊಂದಿವೆ—ನಿಮ್ಮ ಭಾಷೆಗೆ ಅಧಿಕೃತ ಆಕ್ಷನ್ ಅನ್ನು ಪರಿಶೀಲಿಸಿ.

ಹಂತ 2: ನಿಮ್ಮ ಬೇಸ್ ಇಮೇಜ್ ಅನ್ನು ಆಡಿಟ್ ಮಾಡಿ

ನಿಮ್ಮ ವರ್ಕ್‌ಫ್ಲೋ ಬಳಸುತ್ತಿದ್ದರೆ runs-on: ubuntu-latest, ಆ ಇಮೇಜ್ ಏನನ್ನು ಒಳಗೊಂಡಿದೆ ಎಂಬುದನ್ನು ಪರಿಶೀಲಿಸಿ. ನಿಮಗೆ Node.js ಮಾತ್ರ ಅಗತ್ಯವಿದ್ದರೆ, ಅಧಿಕೃತ Node ಇಮೇಜ್‌ಗೆ (docker://node:20) ಅಥವಾ GitHub ನ ಲೈಟ್‌ವೇಟ್ ಆವೃತ್ತಿಗೆ ಬದಲಾಯಿಸುವುದನ್ನು ಪರಿಗಣಿಸಿ. ನಿಮಗೆ ಕಸ್ಟಮ್ ಸೆಟಪ್ ಅಗತ್ಯವಿದ್ದರೆ, ಒಮ್ಮೆ ಮಿನಿಮಲ್ ಇಮೇಜ್ ಬಿಲ್ಡ್ ಮಾಡಿ ಮತ್ತು ಪುಶ್ ಮಾಡಿ.

ಹಂತ 3: ನಿಧಾನಗತಿಯ ಜಾಬ್‌ಗಳನ್ನು ಪ್ಯಾರಲಲ್ ಜಾಬ್‌ಗಳಾಗಿ ವಿಭಜಿಸಿ

ನಿಮ್ಮ ವರ್ಕ್‌ಫ್ಲೋ YAML ಅನ್ನು ಪರಿಶೀಲಿಸಿ. ಪರಸ್ಪರ ಅವಲಂಬಿಸದ ಸೀಕ್ವೆನ್ಷಿಯಲ್ ಜಾಬ್‌ಗಳಿದ್ದರೆ, ಅವುಗಳನ್ನು ವಿಭಜಿಸಿ. ಉದಾಹರಣೆಗೆ:

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm run lint

  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm run test

ಈಗ lint ಮತ್ತು test ಅನುಕ್ರಮವಾಗಿ ರನ್ ಆಗುವ ಬದಲಿಗೆ ಒಂದೇ ಸಮಯದಲ್ಲಿ ರನ್ ಆಗುತ್ತವೆ.

ಹಂತ 4: ಅನಗತ್ಯ ಆರ್ಟಿಫ್ಯಾಕ್ಟ್‌ಗಳನ್ನು ತೆಗೆದುಹಾಕಿ

ನಿಮ್ಮ ವರ್ಕ್‌ಫ್ಲೋನಲ್ಲಿ ಗಾಗಿ ಪರಿಶೀಲಿಸಿ actions/upload-artifact. ಆರ್ಟಿಫ್ಯಾಕ್ಟ್ ಅನ್ನು ಮತ್ತೊಂದು ಜಾಬ್ ಬಳಸದಿದ್ದರೆ ಅಥವಾ ಹಸ್ತಚಾಲಿತವಾಗಿ ಡೌನ್‌ಲೋಡ್ ಮಾಡದಿದ್ದರೆ, ಅದನ್ನು ತೆಗೆದುಹಾಕಿ. ಡಿಬಗ್ ಮಾಡಲು ನೀವು ಆರ್ಟಿಫ್ಯಾಕ್ಟ್‌ಗಳನ್ನು ಇಟ್ಟುಕೊಂಡರೆ, ಕನಿಷ್ಠ retention ಸಮಯವನ್ನು ಹೊಂದಿಸಿ:

- uses: actions/upload-artifact@v4
  if: failure()
  with:
    name: logs-on-failure
    retention-days: 7

ಇದು ವಿಫಲವಾದಾಗ ಮಾತ್ರ ಲಾಗ್‌ಗಳನ್ನು ಅಪ್‌ಲೋಡ್ ಮಾಡುತ್ತದೆ ಮತ್ತು ಒಂದು ವಾರದ ನಂತರ ಅವುಗಳನ್ನು ಅಳಿಸುತ್ತದೆ.

ಹಂತ 5: ಮ್ಯಾಟ್ರಿಕ್ಸ್ ನಕಲನ್ನು ಪರಿಶೀಲಿಸಿ

ನಿಮ್ಮ ವರ್ಕ್‌ಫ್ಲೋನಲ್ಲಿ ಗಾಗಿ ಹುಡುಕಿ matrix: ಮತ್ತು ಪ್ರತಿಯೊಂದನ್ನೂ ಪರಿಶೀಲಿಸಿ. ಮ್ಯಾಟ್ರಿಕ್ಸ್ ನೀವು ಬಯಸಿದ ನಡವಳಿಕೆಯನ್ನು ಬದಲಾಯಿಸದಿದ್ದರೆ, ಅದನ್ನು ತೆಗೆದುಹಾಕಿ. ಪ್ರತಿ ಬಿಲ್ಡ್ ಅನ್ನು ಎರಡೆರಡು ಬಾರಿ ರನ್ ಮಾಡುವ ಮ್ಯಾಟ್ರಿಕ್ಸ್ ವ್ಯರ್ಥ ತೂಕವಾಗಿದೆ.

ಹಂತ 6: ಹಂತಗಳ ಅನುಕ್ರಮವನ್ನು ಪರಿಶೀಲಿಸಿ

ಒಂದು ಜಾಬ್ ಒಳಗೆ, ಪ್ರತಿಯೊಂದು ಹಂತವು ಅನುಕ್ರಮವಾಗಿ ರನ್ ಆಗುತ್ತದೆ. ಅನುಕ್ರಮವು ಸರಿಯಾಗಿದೆಯೇ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ. ಒಂದು ಹಂತವು ನಿಧಾನವಾಗಿದ್ದು ಅದರ ಫಲಿತಾಂಶವನ್ನು ನಂತರದ ಹಂತದಲ್ಲಿ ಬಳಸಿದರೆ, ಅದನ್ನು ಬಳಸುವ ಸ್ಥಳಕ್ಕೆ ಹತ್ತಿರ ಸರಿಸುವುದನ್ನು ಪರಿಗಣಿಸಿ. ಒಂದು ಹಂತವು ವೇಗವಾಗಿ ಮತ್ತು ಸ್ವತಂತ್ರವಾಗಿದ್ದರೆ, ಅದನ್ನು ಮೊದಲಿಗೆ ಸರಿಸಿ ಇದರಿಂದ ಅದು ಬೇಗನೆ ವಿಫಲಗೊಳ್ಳುತ್ತದೆ.

ಸಮಯದೊಂದಿಗೆ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುವುದು

ಒಮ್ಮೆ ನೀವು ಆಪ್ಟಿಮೈಸ್ ಮಾಡಿದ ನಂತರ, ಅದನ್ನು ಮರೆಯಬೇಡಿ. CI ವರ್ಕ್‌ಫ್ಲೋಗಳು ಬದಲಾಗುತ್ತವೆ—ಡಿಪೆಂಡೆನ್ಸಿಗಳು ದೊಡ್ಡದಾಗುತ್ತವೆ, ಹೊಸ ಹಂತಗಳು ಸೇರ್ಪಡೆಯಾಗುತ್ತವೆ, ಇಮೇಜ್‌ಗಳು ಬದಲಾಗುತ್ತವೆ. ನಿಮ್ಮ ಅತ್ಯಂತ ನಿಧಾನಗತಿಯ ವರ್ಕ್‌ಫ್ಲೋ ಅನ್ನು ಪರಿಶೀಲಿಸಲು ಮಾಸಿಕ ರಿಮೈಂಡರ್ ಹೊಂದಿಸಿ. ಅದು ನಿಧಾನವಾಗುತ್ತಿದ್ದರೆ, ಸಮಸ್ಯೆಯಾಗುವ ಮೊದಲೇ ಪರಿಶೀಲಿಸಿ.

ಕೆಲವು ತಂಡಗಳು GitHub Actions ಮೆಟ್ರಿಕ್ಸ್‌ಗಳನ್ನು ಮಾನಿಟರಿಂಗ್ ಡ್ಯಾಶ್‌ಬೋರ್ಡ್‌ಗೆ ಎಕ್ಸ್‌ಪೋರ್ಟ್ ಮಾಡುತ್ತವೆ. ಇದು ಮುಂದುವರಿದ ಹಂತವಾಗಿದೆ, ಆದರೆ ನೀವು ಅನೇಕ ವರ್ಕ್‌ಫ್ಲೋಗಳನ್ನು ಹೊಂದಿದ್ದರೆ, ಇದು ಬದಲಾವಣೆಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ತೋರಿಸುವ ಮೂಲಕ ಉಪಯುಕ್ತವಾಗುತ್ತದೆ.

ತೀರ್ಮಾನ

ನಿಧಾನಗತಿಯ CI ನಿಮ್ಮ ತಂಡದ ವೇಗದ ಮೇಲಿನ ತೆರಿಗೆಯಾಗಿದೆ, ಅದು ಎಂದಿಗೂ ಬಿಲ್‌ನಲ್ಲಿ ಕಾಣಿಸುವುದಿಲ್ಲ. ಇದು ವಾರಕ್ಕೆ ನೂರಾರು ರನ್‌ಗಳಲ್ಲಿ ಅದೃಶ್ಯವಾಗಿ ಹೆಚ್ಚಾಗುತ್ತದೆ. ಪರಿಹಾರಗಳು ಕಷ್ಟವೇನಲ್ಲ—ಕ್ಯಾಶಿಂಗ್, ಪ್ಯಾರಲಲ್ ಜಾಬ್‌ಗಳು, ವ್ಯರ್ಥವಾದವುಗಳನ್ನು ತೆಗೆದುಹಾಕುವುದು—ಆದರೆ ಅವುಗಳಿಗೆ ಮೊದಲಿಗೆ ಸಮಸ್ಯೆಯನ್ನು ಗುರುತಿಸುವುದು ಅಗತ್ಯ. ಈ ವಾರ ನಿಮ್ಮ ವರ್ಕ್‌ಫ್ಲೋಗಳನ್ನು ಪರಿಶೀಲಿಸಲು ಒಂದು ಗಂಟೆ ವ್ಯಯಿಸಿ. ಪ್ರತಿ ರನ್‌ನಲ್ಲೂ 5-10 ನಿಮಿಷಗಳ ವ್ಯರ್ಥ ಸಮಯವನ್ನು ನೀವು ಕಂಡುಕೊಳ್ಳುವ ಸಾಧ್ಯತೆಯಿದೆ. ಅದು ನಿಮ್ಮ ಭವಿಷ್ಯದ ಕೆಲಸಕ್ಕೆ ನೀಡುವ ಕೊಡುಗೆಯಾಗಿದೆ.

ಪ್ರಯೋಜನಗಳು

• ವೇಗದ ಫೀಡ್‌ಬ್ಯಾಕ್ ಲೂಪ್‌ಗಳು ಡೆವಲಪರ್‌ಗಳ ಕೆಲಸಕ್ಕೆ ಅಡೆತಡೆಯಾಗದಂತೆ ಮತ್ತು ನಿರಂತರವಾಗಿರಲು ಸಹಾಯ ಮಾಡುತ್ತವೆ.
• ರನ್‌ಗಳು ವೇಗವಾಗಿ ಪೂರ್ಣಗೊಳ್ಳುವುದರಿಂದ ಕ್ಲೌಡ್ ಕಂಪ್ಯೂಟ್ ವೆಚ್ಚಗಳು ಕಡಿಮೆಯಾಗುತ್ತವೆ.
• ಸಮಸ್ಯೆಗಳನ್ನು ಬೇಗನೆ ಗುರುತಿಸುವುದು (ಉದಾಹರಣೆಗೆ, ವಿಭಜಿತ ಜಾಬ್‌ಗಳು ಬೇಗನೆ ವಿಫಲಗೊಳ್ಳುತ್ತವೆ).
• ಉತ್ತಮ ಡೆವಲಪರ್ ಅನುಭವ; 15 ನಿಮಿಷ ಕಾಯುವುದಕ್ಕಿಂತ 3 ನಿಮಿಷ ಕಾಯಲು ಜನರು ಹೆಚ್ಚು ಸಂತೋಷಪಡುತ್ತಾರೆ.
• ಸಣ್ಣ ಬದಲಾವಣೆಗಳು ವಾರಕ್ಕೆ ಹತ್ತಾರು ರನ್‌ಗಳಲ್ಲಿ ಗಮನಾರ್ಹ ಸಮಯದ ಉಳಿತಾಯವಾಗಿ ಬದಲಾಗುತ್ತವೆ.
• ಅಳೆಯುವುದು ಸುಲಭ; ಡ್ಯಾಶ್‌ಬೋರ್ಡ್ ಡೇಟಾ ಈಗಾಗಲೇ GitHub ನಲ್ಲಿ ಲಭ್ಯವಿದೆ.

ಅನುಕೂಲಕರವಲ್ಲದ ಅಂಶಗಳು

• ಆಡಿಟ್ ಮತ್ತು ನಿರ್ವಹಣೆ ಅಗತ್ಯವಿದೆ; ಪರಿಶೀಲನೆಯಿಲ್ಲದೆ ವರ್ಕ್‌ಫ್ಲೋಗಳು ಆಪ್ಟಿಮೈಸ್ ಆಗಿ ಉಳಿಯುವುದಿಲ್ಲ.
• ಹೆಚ್ಚಿನ ಪ್ರಮಾಣದ ಕ್ಯಾಶಿಂಗ್ ಪ್ರೊಡಕ್ಷನ್‌ವರೆಗೆ ಡಿಪೆಂಡೆನ್ಸಿ ಬಗ್‌ಗಳನ್ನು ಮರೆಮಾಡಬಹುದು.
• ಜಾಬ್‌ಗಳನ್ನು ಹೆಚ್ಚು ವಿಭಜಿಸುವುದು ಸಂಕೀರ್ಣತೆಯನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ; ಹೆಚ್ಚಿನ ಜಾಬ್‌ಗಳು ಎಂದರೆ ಡಿಬಗ್ ಮಾಡಲು ಹೆಚ್ಚಿನ ಅಂಶಗಳು.
• ಕನಿಷ್ಠ (minimal) ಇಮೇಜ್‌ಗಳಲ್ಲಿ ಕೆಲವೊಮ್ಮೆ ನಿಮಗೆ ನಂತರ ಅಗತ್ಯವಿರುವ ಟೂಲ್‌ಗಳು ಇರುವುದಿಲ್ಲ, ಇದು ಪುನಃ ಕೆಲಸ ಮಾಡುವ ಅಗತ್ಯವನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ.
• ಆರ್ಟಿಫ್ಯಾಕ್ಟ್ ಕ್ಲೀನಪ್ ನೀತಿಗಳಿಂದ ಡಿಬಗ್ ಮಾಡಲು ಅಗತ್ಯವಿರುವ ಲಾಗ್‌ಗಳನ್ನು ಕಳೆದುಕೊಳ್ಳುವ ಅಪಾಯವಿದೆ.
• ಸಾಕಷ್ಟು ಕಾನ್ಕರನ್ಸಿ ಕ್ಯೋಟಾ ಇದ್ದರೆ ಮಾತ್ರ ಪ್ಯಾರಲಲೈಸೇಶನ್ ಸಹಾಯ ಮಾಡುತ್ತದೆ; GitHub ನ ಉಚಿತ ಟೈರ್ ಸೀಮಿತವಾಗಿದೆ.

ಎಚ್ಚರಿಕೆ

ಈ ಲೇಖನದಲ್ಲಿರುವ ಎಲ್ಲಾ ಹೆಸರುಗಳು, ಕಾನ್ಫಿಗರೇಶನ್ ಮೌಲ್ಯಗಳು ಮತ್ತು ಪ್ಲೇಸ್‌ಹೋಲ್ಡರ್‌ಗಳು (ಉದಾಹರಣೆಗೆ, node:20, ubuntu-latest, app.example.com) ಕೇವಲ ಉದಾಹರಣೆಯ ಉದ್ದೇಶಗಳಿಗಾಗಿ ಮಾತ್ರ. ಉತ್ಪಾದನೆಗೆ (production) ಯಾವುದೇ ವರ್ಕ್‌ಫ್ಲೋ ಅನ್ನು ನಿಯೋಜಿಸುವ (deploy) ಮೊದಲು, ಅದನ್ನು ಸ್ಟೇಜಿಂಗ್ ಬ್ರಾಂಚ್‌ನಲ್ಲಿ ಸಂಪೂರ್ಣವಾಗಿ ಪರೀಕ್ಷಿಸಿ. ನಿಮ್ಮ ನಿರ್ದಿಷ್ಟ ಸೆಟಪ್, ಭಾಷೆಯ ಆವೃತ್ತಿಗಳು ಮತ್ತು ಮೂಲಸೌಕರ್ಯಗಳು ಭಿನ್ನವಾಗಿರಬಹುದು. ಒಂದು ಪ್ರಾಜೆಕ್ಟ್‌ಗೆ ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಕ್ಯಾಶಿಂಗ್ ತಂತ್ರಗಳು ಇನ್ನೊಂದಕ್ಕೆ ಸೂಕ್ತವಾಗದಿರಬಹುದು. ನಿಮ್ಮ ನೈಜ ವಾತಾವರಣದಲ್ಲಿ ಯಾವಾಗಲೂ ಕಾರ್ಯಕ್ಷಮತೆಯ ಸುಧಾರಣೆಗಳನ್ನು ಪರಿಶೀಲಿಸಿ, ಮತ್ತು ಪಾರ್ಶ್ವಪರಿಣಾಮಗಳಿಗಾಗಿ (ಉದಾಹರಣೆಗೆ, ಹಳೆಯ ಕ್ಯಾಶ್‌ನಿಂದಾಗಿ ಹಳೆಯ ಡಿಪೆಂಡೆನ್ಸಿಗಳು ಉಳಿಯುವುದು) ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಿ. ನಿಮ್ಮ ಸ್ವಂತ ಅಪಾಯದಲ್ಲಿ ಮುಂದುವರಿಯಿರಿ.

ಪದೇ ಪದೇ ಕೇಳಲಾಗುವ ಪ್ರಶ್ನೆಗಳು

• GitHub Actions ನಲ್ಲಿ ಪ್ರತಿ ರೆಪೊಸಿಟರಿಗೆ ಗರಿಷ್ಠ ಕ್ಯಾಶ್ ಗಾತ್ರ ಎಷ್ಟು?
• ನನ್ನ ವರ್ಕ್‌ಫ್ಲೋನಲ್ಲಿ GitHub Actions ಕ್ಯಾಶಿಂಗ್ ನಿಜವಾಗಿಯೂ ಬಳಕೆಯಾಗುತ್ತಿದೆಯೇ ಎಂದು ತಿಳಿಯುವುದು ಹೇಗೆ?
• ನನ್ನ CI ಅನ್ನು ವೇಗಗೊಳಿಸಲು ನಾನು ಕಸ್ಟಮ್ Docker ಇಮೇಜ್ ಅನ್ನು ಬಳಸಬಹುದೇ?
• ಕ್ಯಾಶ್ ರಚಿಸಿದ ನಂತರ ನನ್ನ ಮೊದಲ ರನ್ ಸಮಯವನ್ನು ಕಡಿಮೆ ಮಾಡುವ ಬದಲು ಹೆಚ್ಚು ಸಮಯವನ್ನು ಏಕೆ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ?
• ಕಾನ್ಕರನ್ಸಿ ಕ್ಯೋಟಾ ಬಳಕೆಯನ್ನು ಹೆಚ್ಚಿಸದೆ GitHub Actions ನಲ್ಲಿ ಜಾಬ್‌ಗಳನ್ನು ಪ್ಯಾರಲಲೈಸ್ ಮಾಡುವುದು ಹೇಗೆ?
• node_modules ಅನ್ನು ಕ್ಯಾಶ್ ಮಾಡುವುದು ಉತ್ತಮವೇ ಅಥವಾ ಕೇವಲ lock ಫೈಲ್ ಅನ್ನೇ?
• ನಿಧಾನಗತಿಯ CI ರನ್‌ಗಳಿಂದಾಗಿ GitHub ನನ್ನ ವರ್ಕ್‌ಫ್ಲೋ ಅನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ರದ್ದುಗೊಳಿಸಬಹುದೇ?
• ನನ್ನ GitHub Actions ವರ್ಕ್‌ಫ್ಲೋಗಳನ್ನು ನಾನು ಎಷ್ಟು ಬಾರಿ ಪರಿಶೀಲಿಸಬೇಕು ಮತ್ತು ಅಪ್‌ಡೇಟ್ ಮಾಡಬೇಕು?

ಟ್ಯಾಗ್‌ಗಳು

#github #actions #ci #cicd #devops #performance #optimization #workflows #automation #testing