Monorepo ETL ಗಾಗಿ 4 GitHub Actions ಮಾದರಿಗಳು
ಒಂದು monorepo ನಿಂದ ಮೂರು ಸೈಟ್ಗಳನ್ನು ನಡೆಸುವುದರಿಂದ ಸಮಸ್ಯೆಗಳು ಉಂಟಾಗುತ್ತವೆ. ನೀವು ಮೂರು ಪ್ರತ್ಯೇಕ ETL ಕೆಲಸಗಳು (jobs), ಮೂರು ಕಂಟೆಂಟ್ ರೀಬಿಲ್ಡ್ಗಳು ಮತ್ತು ಮೂರು ಡಿಪ್ಲಾಯ್ಮೆಂಟ್ ಪೈಪ್ಲೈನ್ಗಳನ್ನು ಎದುರಿಸುತ್ತೀರಿ. ನೀವು ಅವುಗಳನ್ನು ಸಮನ್ವಯಗೊಳಿಸದಿದ್ದರೆ, ಅವುಗಳ ನಡುವೆ ಘರ್ಷಣೆ ಉಂಟಾಗುತ್ತದೆ.
ಈ ಸೆಟಪ್ ಅನ್ನು ಸ್ಥಿರಗೊಳಿಸಲು ನಾನು ಆರು ವಾರಗಳ ಕಾಲ ವೇಳಾಪಟ್ಟಿಗಳನ್ನು (schedules) ಪರೀಕ್ಷಿಸಿದೆ. ನಾನು ಬಳಸುವ ನಾಲ್ಕು ಮಾದರಿಗಳು ಇಲ್ಲಿವೆ.
1. Cron Jobs ಗಾಗಿ Time Offsets ಬಳಸಿ
ಎಲ್ಲಾ ETL ಕೆಲಸಗಳನ್ನು ಒಂದೇ ಸಮಯದಲ್ಲಿ ನಡೆಸುವುದರಿಂದ ವೈಫಲ್ಯಗಳು ಸಂಭವಿಸುತ್ತವೆ. ಕೆಲಸಗಳು API rate limits ಗಾಗಿ ಸ್ಪರ್ಧಿಸುತ್ತವೆ. HuggingFace ಅಥವಾ GitHub 429 error ಅನ್ನು ನೀಡಿದಾಗ, run ಫೇಲ್ ಆಗುತ್ತದೆ.
ಇದನ್ನು ತಡೆಯಲು ನಾನು 30 ನಿಮಿಷಗಳ offsets ಬಳಸುತ್ತೇನೆ.
- ಮೊದಲ ಕೆಲಸವು 02:00 ಕ್ಕೆ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ
- ಎರಡನೇ ಕೆಲಸವು 02:30 ಕ್ಕೆ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ
- ಮೂರನೇ ಕೆಲಸವು 03:00 ಕ್ಕೆ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ
ಮುಂದಿನ ಕೆಲಸ ಪ್ರಾರಂಭವಾಗುವ ಮೊದಲು ಒಂದು ಭಾರೀ pull ಅನ್ನು ಪೂರ್ಣಗೊಳಿಸಲು ಮೂವತ್ತು ನಿಮಿಷಗಳು ಸಾಕಾಗುತ್ತವೆ. ಇದು ನಿಮ್ಮ logs ಅನ್ನು ಸ್ವಚ್ಛವಾಗಿಡುತ್ತದೆ ಮತ್ತು API ಘರ್ಷಣೆಗಳನ್ನು ತಡೆಯುತ್ತದೆ.
2. ಅನಗತ್ಯ ರೀಬಿಲ್ಡ್ಗಳನ್ನು ತಡೆಯಲು Skip Flags ಬಳಸಿ
ಪ್ರತಿ ETL ಕೆಲಸವು Vercel deployment ನೊಂದಿಗೆ ಕೊನೆಗೊಳ್ಳುತ್ತದೆ. ಆರ್ಟಿಕಲ್ ಕಮಿಟ್ಗಳು (article commits) ಕೂಡ ರೀಬಿಲ್ಡ್ಗಳನ್ನು ಪ್ರಚೋದಿಸಿದಾಗ ಸಮಸ್ಯೆ ಉಂಟಾಗುತ್ತದೆ. ಯಾವುದೇ ಯೋಜನೆ ಇಲ್ಲದಿದ್ದರೆ, ಪ್ರತಿ ಆರ್ಟಿಕಲ್ ಅಪ್ಡೇಟ್ ಕೂಡ ಮೂರೂ ಸೈಟ್ಗಳನ್ನು ರೀಬಿಲ್ಡ್ ಮಾಡಲು ಒತ್ತಾಯಿಸುತ್ತದೆ. ಇದು build minutes ಅನ್ನು ವ್ಯರ್ಥ ಮಾಡುತ್ತದೆ.
ನಾನು ETL commit ಸಂದೇಶಗಳಲ್ಲಿ [skip publish-articles] ಟ್ಯಾಗ್ ಬಳಸುತ್ತೇನೆ.
ಈ ಫ್ಲ್ಯಾಗ್ ಅನ್ನು ಪರಿಶೀಲಿಸಲು ನಾನು ನನ್ನ workflow ನಲ್ಲಿ ಒಂದು ಹಂತವನ್ನು (step) ಸೇರಿಸಿದ್ದೇನೆ. ಒಂದು ವೇಳೆ ಆ ಟ್ಯಾಗ್ ಇದ್ದರೆ, workflow ರೀಬಿಲ್ಡ್ ಮತ್ತು ಡಿಪ್ಲಾಯ್ ಹಂತವನ್ನು ಬಿಟ್ಟುಬಿಡುತ್ತದೆ (skips). ಇದು ETL ಪೈಪ್ಲೈನ್ಗಳನ್ನು ಆರ್ಟಿಕಲ್ ಪೈಪ್ಲೈನ್ಗಳಿಂದ ಪ್ರತ್ಯೇಕವಾಗಿಡುತ್ತದೆ.
3. ನಿರ್ದಿಷ್ಟ ಸೈಟ್ಗಳನ್ನು ಗುರಿಯಾಗಿಸಲು Path Filters ಬಳಸಿ
ಒಂದು ಸೈಟ್ನ ಅಪ್ಡೇಟ್ ಮೂರು ಡಿಪ್ಲಾಯ್ಮೆಂಟ್ಗಳನ್ನು ಪ್ರಚೋದಿಸಬೇಕೆಂದು ನೀವು ಬಯಸುವುದಿಲ್ಲ. ನಾನು ಪ್ರತಿಯೊಂದು ಸೈಟ್ನ workflow ಅನ್ನು ಅದರ ಸ್ವಂತ ಫೋಲ್ಡರ್ ಮತ್ತು shared packages ಫೋಲ್ಡರ್ ಅನ್ನು ಮಾತ್ರ ಗಮನಿಸಲು (watch) ಕಾನ್ಫಿಗರ್ ಮಾಡುತ್ತೇನೆ.
ಉದಾಹರಣೆಯ ತರ್ಕ (logic):
- AI tools ಸೈಟ್ ಕೇವಲ
apps/ai-tools/ಅನ್ನು ಮಾತ್ರ ಗಮನಿಸುತ್ತದೆ - OSS ಸೈಟ್ ಕೇವಲ
apps/oss-alternatives/ಅನ್ನು ಮಾತ್ರ ಗಮನಿಸುತ್ತದೆ
ನೀವು shared ಡೈರೆಕ್ಟರಿಯಲ್ಲಿ ಕೋಡ್ ಬದಲಾಯಿಸಿದರೆ, ಎಲ್ಲಾ ಸೈಟ್ಗಳು ರೀಬಿಲ್ಡ್ ಆಗುತ್ತವೆ. shared ಕೋಡ್ ಬದಲಾವಣೆಗಳು ಅಪರೂಪವಾಗಿರುವುದರಿಂದ ನಾನು ಈ ಹೊಂದಾಣಿಕೆಯನ್ನು (trade-off) ಒಪ್ಪಿಕೊಳ್ಳುತ್ತೇನೆ.
4. ನಿಯಂತ್ರಣಕ್ಕಾಗಿ Manual Dispatch ಅನ್ನು ಸೇರಿಸಿ
Cron ದೈನಂದಿನ ದಿನಚರಿಯನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ. Manual dispatch ಉಳಿದೆಲ್ಲವನ್ನೂ ನಿರ್ವಹಿಸುತ್ತದೆ. ನಾನು workflow_dispatch ಅನ್ನು ಬಳಸುತ್ತೇನೆ ಇದರಿಂದ ನಾನು:
- ಫೇಲ್ ಆದ ETL ಕೆಲಸವನ್ನು ಮರು-ಚಾಲನೆ (re-run) ಮಾಡಲು
- ಡೇಟಾವನ್ನು ಸೇರಿಸಿದ ನಂತರ ಫೋರ್ಸ್ ರಿಫ್ರೆಶ್ ಮಾಡಲು
- ಡೇಟಾಬೇಸ್ಗೆ ಬರೆಯುವ ಮೊದಲು ಡೇಟಾವನ್ನು ಪರೀಕ್ಷಿಸಲು dry run ನಡೆಸಲು
GitHub UI ಈ ಆಯ್ಕೆಗಳಿಗಾಗಿ ಡ್ರಾಪ್ಡೌನ್ ಮೆನುವನ್ನು ತೋರಿಸುತ್ತದೆ. ಇದು ಟೈಪಿಂಗ್ ತಪ್ಪುಗಳನ್ನು (typos) ತಡೆಯುತ್ತದೆ ಮತ್ತು ಡಿಬಗ್ ಮಾಡುವುದನ್ನು ಸುಲಭಗೊಳಿಸುತ್ತದೆ.
ಸಾರಾಂಶ
ಈ ಮಾದರಿಗಳು ಸಂಕೀರ್ಣವಾಗಿಲ್ಲ. ಅವು ಸ್ಪಷ್ಟವಾಗಿವೆ. ಈ ನಿಯಮಗಳನ್ನು ದಾಖಲಿಸಲು ನಾನು ನನ್ನ ರೆಪೊಸಿಟರಿಯಲ್ಲಿ (repository) ಒಂದು ಸರಳ markdown ಫೈಲ್ ಅನ್ನು ಇಡುತ್ತೇನೆ. ಇದರಿಂದ ನಾನು ಹೊಸ workflows ಸೇರಿಸುವಾಗ ಸಿಸ್ಟಮ್ ಹಾಳಾಗದಂತೆ ನೋಡಿಕೊಳ್ಳಬಹುದು.