Monorepo ETL માટે 4 GitHub Actions પેટર્ન
એક જ monorepo માંથી ત્રણ સાઇટ્સ ચલાવવાથી સમસ્યાઓ ઊભી થાય છે. તમારે ત્રણ અલગ-અલગ ETL જોબ્સ, ત્રણ કન્ટેન્ટ રીબિલ્ડ્સ અને ત્રણ ડિપ્લોયમેન્ટ પાઇપલાઇન્સનો સામનો કરવો પડે છે. જો તમે તેમને સંકલિત (coordinate) ન કરો, તો તેઓ એકબીજા સાથે અથડાય છે.
આ સેટઅપને સ્થિર કરવા માટે મેં શેડ્યૂલ ટેસ્ટ કરવામાં છ અઠવાડિયા વિતાવ્યા છે. અહીં તે ચાર પેટર્ન છે જે હું વાપરું છું.
- Cron Jobs માટે Time Offsets નો ઉપયોગ કરો
બધા ETL જોબ્સ એકસાથે ચલાવવાથી નિષ્ફળતા (failures) આવે છે. જોબ્સ API rate limits માટે સ્પર્ધા કરે છે. જ્યારે HuggingFace અથવા GitHub 429 error આપે છે, ત્યારે રન નિષ્ફળ જાય છે.
આને રોકવા માટે હું 30-મિનિટના offsets વાપરું છું.
- પહેલો જોબ 02:00 વાગ્યે શરૂ થાય છે
- બીજો જોબ 02:30 વાગ્યે શરૂ થાય છે
- ત્રીજો જોબ 03:00 વાગ્યે શરૂ થાય છે
આગામી જોબ શરૂ થાય તે પહેલાં હેવી પુલ (heavy pull) પૂર્ણ કરવા માટે ત્રીસ મિનિટ પૂરતો સમય છે. આ તમારા લોગ્સ (logs) ક્લીન રાખે છે અને API collisions ને અટકાવે છે.
- બિનજરૂરી રીબિલ્ડ્સ રોકવા માટે Skip Flags નો ઉપયોગ કરો
દરેક ETL જોબ Vercel deployment સાથે સમાપ્ત થાય છે. સમસ્યા ત્યારે ઊભી થાય છે જ્યારે આર્ટિકલ કમિટ્સ (article commits) પણ રીબિલ્ડ્સ ટ્રિગર કરે છે. જો કોઈ પ્લાન ન હોય, તો દરેક આર્ટિકલ અપડેટ ત્રણેય સાઇટ્સને રીબિલ્ડ કરવા માટે મજબૂર કરે છે. આનાથી બિલ્ડ મિનિટ્સનો બગાડ થાય છે.
હું ETL commit મેસેજમાં [skip publish-articles] ટેગનો ઉપયોગ કરું છું.
મેં આ ફ્લેગ તપાસવા માટે મારા workflow માં એક સ્ટેપ ઉમેર્યું છે. જો ટેગ હોય, તો workflow બિલ્ડ અને ડિપ્લોય સ્ટેપને સ્કીપ કરે છે. આ ETL પાઇપલાઇન્સને આર્ટિકલ પાઇપલાઇન્સથી અલગ રાખે છે.
- ચોક્કસ સાઇટ્સને ટાર્ગેટ કરવા માટે Path Filters નો ઉપયોગ કરો
તમે નથી ઈચ્છતા કે એક સાઇટના અપડેટથી ત્રણ ડિપ્લોયમેન્ટ્સ ટ્રિગર થાય. હું દરેક સાઇટના workflow ને ફક્ત તેના પોતાના ફોલ્ડર અને shared packages ફોલ્ડર પર નજર રાખવા માટે કોન્ફિગર કરું છું.
ઉદાહરણ લોજિક:
- AI tools સાઇટ ફક્ત apps/ai-tools/ ને જ જુએ છે
- OSS સાઇટ ફક્ત apps/oss-alternatives/ ને જ જુએ છે
જો તમે shared ડિરેક્ટરીમાં કોડ બદલો છો, તો બધી સાઇટ્સ રીબિલ્ડ થશે. હું આ trade-off સ્વીકારું છું કારણ કે shared કોડના ફેરફારો ભાગ્યે જ થાય છે.
- કંટ્રોલ માટે Manual Dispatch ઉમેરો
Cron દૈનિક રૂટિન સંભાળે છે. Manual dispatch બાકીનું બધું સંભાળે છે. હું workflow_dispatch વાપરું છું જેથી હું:
- નિષ્ફળ ગયેલ ETL જોબને ફરીથી ચલાવી શકું (Re-run)
- ડેટા ઉમેર્યા પછી રિફ્રેશ કરવા માટે મજબૂર (Force) કરી શકું
- ડેટાબેઝમાં લખ્યા વિના ડેટા ટેસ્ટ કરવા માટે dry run ચલાવી શકું
GitHub UI આ પસંદગીઓ માટે ડ્રોપડાઉન મેનૂ બતાવે છે. આનાથી ટાઈપો (typos) અટકે છે અને debugging સરળ બને છે.
સારાંશ
આ પેટર્ન જટિલ નથી. તે સ્પષ્ટ છે. હું આ નિયમોને ડોક્યુમેન્ટ કરવા માટે મારા રિપોઝિટરીમાં એક સાદી markdown ફાઇલ રાખું છું. આ સુનિશ્ચિત કરે છે કે જ્યારે હું નવા workflows ઉમેરું ત્યારે સિસ્ટમ બગડે નહીં.