Monorepo ETL-க்கான 4 GitHub Actions முறைகள்
ஒரே monorepo-விலிருந்து மூன்று தளங்களை இயக்குவது சிக்கல்களை உருவாக்குகிறது. நீங்கள் மூன்று தனித்தனி ETL வேலைகள் (jobs), மூன்று உள்ளடக்க மறுசீரமைப்புகள் (content rebuilds) மற்றும் மூன்று deployment pipelines ஆகியவற்றைக் கையாள வேண்டியிருக்கும். அவற்றை நீங்கள் ஒருங்கிணைக்காவிட்டால், அவை ஒன்றோடொன்று மோதிக்கொள்ளும்.
இந்த அமைப்பை நிலைப்படுத்த கால அட்டவணைகளைச் சோதிக்க நான் ஆறு வாரங்கள் செலவிட்டேன். நான் பயன்படுத்தும் நான்கு முறைகள் இதோ.
1. Cron Jobs-களுக்கு நேர இடைவெளிகளை (Time Offsets) பயன்படுத்தவும்
அனைத்து ETL வேலைகளையும் ஒரே நேரத்தில் இயக்குவது தோல்விகளுக்கு வழிவகுக்கும். வேலைகள் API rate limits-க்காகப் போட்டியிடும். HuggingFace அல்லது GitHub ஒரு 429 பிழையைத் (error) திருப்பியனுப்பும்போது, அந்த இயக்கம் தோல்வியடையும்.
இதைத் தவிர்க்க நான் 30 நிமிட இடைவெளிகளைப் பயன்படுத்துகிறேன்.
- முதல் வேலை 02:00-க்குத் தொடங்குகிறது
- இரண்டாவது வேலை 02:30-க்குத் தொடங்குகிறது
- மூன்றாவது வேலை 03:00-க்குத் தொடங்குகிறது
அடுத்த வேலை தொடங்குவதற்கு முன், ஒரு பெரிய தரவுப் பதிவிறக்கத்தை (heavy pull) முடிக்க முப்பது நிமிடங்கள் போதுமானவை. இது உங்கள் பதிவுகளை (logs) சுத்தமாக வைத்திருக்கவும், API மோதல்களைத் தவிர்க்கவும் உதவுகிறது.
2. தேவையற்ற மறுசீரமைப்புகளைத் தவிர்க்க Skip Flags-களைப் பயன்படுத்தவும்
ஒவ்வொரு ETL வேலையும் ஒரு Vercel deployment-உடன் முடிகிறது. கட்டுரைகளுக்கான commits-களும் மறுசீரமைப்புகளைத் தூண்டும்போது ஒரு சிக்கல் ஏற்படுகிறது. முறையான திட்டம் இல்லையென்றால், ஒவ்வொரு கட்டுரை மாற்றமும் மூன்று தளங்களையும் மறுசீரமைக்கத் தூண்டும். இது build minutes-களை வீணடிக்கும்.
ETL commit செய்திகளில் நான் [skip publish-articles] என்ற டேக்-கைப் (tag) பயன்படுத்துகிறேன்.
இந்த flag இருக்கிறதா என்று சரிபார்க்க எனது workflow-இல் ஒரு படிநிலையைச் சேர்த்துள்ளேன். அந்த டேக் இருந்தால், workflow build மற்றும் deploy படிநிலையைத் தவிர்த்துவிடும். இது ETL pipelines-களை கட்டுரை pipelines-களிலிருந்து தனித்து வைக்கிறது.
3. குறிப்பிட்ட தளங்களைக் குறிவைக்க Path Filters-களைப் பயன்படுத்தவும்
ஒரு தளத்தின் மாற்றம் மூன்று deployment-களைத் தூண்டுவதை நீங்கள் விரும்ப மாட்டீர்கள். ஒவ்வொரு தளத்தின் workflow-யும் அதன் சொந்த ஃபோல்டர் மற்றும் பகிரப்பட்ட பேக்கேஜ் (shared packages) ஃபோல்டரை மட்டும் கவனிக்கும்படி நான் கட்டமைக்கிறேன்.
உதாரண தர்க்கம் (Example logic):
- AI tools தளம்
apps/ai-tools/ஐ மட்டும் கவனிக்கும் - OSS தளம்
apps/oss-alternatives/ஐ மட்டும் கவனிக்கும்
நீங்கள் பகிரப்பட்ட கோப்பகத்தில் (shared directory) குறியீட்டை மாற்றினால், அனைத்து தளங்களும் மறுசீரமைக்கப்படும். பகிரப்பட்ட குறியீடு மாற்றங்கள் அரிதானவை என்பதால், இந்தச் சமரசத்தை (trade-off) நான் ஏற்றுக்கொள்கிறேன்.
4. கட்டுப்பாட்டிற்காக Manual Dispatch-ஐச் சேர்க்கவும்
Cron அன்றாட நடைமுறைகளைக் கையாள்கிறது. Manual dispatch மற்ற அனைத்தையும் கையாள்கிறது. நான் workflow_dispatch-ஐப் பயன்படுத்துகிறேன், இதன் மூலம் என்னால்:
- தோல்வியடைந்த ETL வேலையை மீண்டும் இயக்க (Re-run) முடியும்
- தரவைச் சேர்த்த பிறகு கட்டாயமாகப் புதுப்பிக்க (Force a refresh) முடியும்
- தரவுத்தளத்தில் எழுதாமல், தரவைச் சோதிக்க ஒரு dry run செய்ய முடியும்
GitHub UI இந்தத் தேர்வுகளுக்கான ஒரு dropdown மெனுவைக் காட்டுகிறது. இது எழுத்துப் பிழைகளைத் தவிர்க்கிறது மற்றும் பிழைத்திருத்தத்தை (debugging) எளிதாக்குகிறது.
சுருக்கம்
இந்த முறைகள் சிக்கலானவை அல்ல. அவை தெளிவானவை. இந்த விதிகளை ஆவணப்படுத்த எனது repository-இல் ஒரு எளிய markdown கோப்பை வைத்திருக்கிறேன். இது புதிய workflows-களைச் சேர்க்கும்போது நான் அமைப்பைச் சிதைப்பதைத் தவிர்க்கிறது.