Github Actions का फिर से उपयोग करने से पहले मैं एक बार और सोचूंगा

 (ninkovic.dev)
5 पॉइंट द्वारा GN⁺ 2025-01-22 | 6 टिप्पणियां | WhatsApp पर शेयर करें
  • GitHub Actions को लेकर असंतोष
    • टीम में लगभग 15 इंजीनियर हैं, और सभी लगातार main branch में code push करते हैं
    • code कई modules में बंटे monorepo के रूप में है, और trunk-based development के जरिए दिन में कई बार deploy होता है
  • कुछ मामलों में GitHub Actions अच्छा काम करता है, लेकिन एक खास scale या environment में इसकी सीमाएँ साफ़ दिखाई देती हैं

Pull request और आवश्यक checks

  • monorepo कई folders में बंटा है, और हर folder के लिए test, build और deploy स्वतंत्र रूप से चलते हैं
  • GitHub Actions की paths feature का उपयोग करके केवल किसी खास folder में बदलाव होने पर वही pipeline trigger की जाती है
  • Pull request merge होने से पहले सभी checks pass होने चाहिए — यह सिद्धांत अच्छा है, लेकिन monorepo structure के साथ मिलकर समस्या पैदा करता है
    • उदाहरण: web-app1 - Unit tests नाम के check को “required” सेट किया गया है, लेकिन अगर web-app1 folder में कोई बदलाव नहीं है तो वह check चलता ही नहीं
    • नतीजतन, चाहे बदलाव सिर्फ एक तरफ के folder में हुआ हो, दूसरे folders से जुड़े tests नहीं चलते और merge करना ही असंभव हो जाता है
  • अगर GitHub required check के नाम के बजाय “इस समय trigger हुए सभी checks pass हों तो merge संभव है” जैसे तरीके से इसे संभालता, तो यह समस्या हल हो सकती थी, लेकिन 3 साल से इसमें कोई बदलाव नहीं हुआ है
  • संबंधित GitHub issue threads 1, 2 में भी इस समस्या का बड़ा असर देखा जा सकता है
  • आखिरकार, इसे workaround करने के लिए अतिरिक्त pipelines चलानी या maintain करनी पड़ती हैं, जो जटिल और महंगी साबित होती हैं

Reusability और YAML

  • जैसे-जैसे pipelines का आकार बढ़ता है, GitHub Actions से उन्हें manage करना और कठिन लगता है
    • बहुत सारे if statements जुड़ जाते हैं, और workflows अलग करने पर भी manage करने वाली files इतनी बढ़ जाती हैं कि maintainability घटती है
  • reuse के समय जहाँ invocation ideally एक line में खत्म होना चाहिए, वहाँ कई lines और duplicate settings चाहिए होती हैं, और .github folder में पहले ही 30 से ज़्यादा files जमा हो चुकी हैं
  • needs clauses में भी refactoring के दौरान हटाए गए jobs का असर ठीक से न दिखे, तो error पकड़ने में समय लगता है
  • GitHub Actions को local में चलाया नहीं जा सकता, इसलिए development और testing मुश्किल हो जाते हैं
    • act जैसे tools मौजूद हैं, लेकिन वास्तविक उपयोग में उन पर कई limitations होती हैं, इसलिए वे अक्सर उम्मीद पर खरे नहीं उतरते

GitHub की उदासीनता

  • ऊपर बताई गई समस्याओं में सबसे बड़ी समस्या यह लगती है कि GitHub इन issues को खास अहमियत देता हुआ नहीं दिखता
  • कई issues वर्षों से खुले हैं, और public roadmap में भी शामिल नहीं हैं, इसलिए सुधार की इच्छा नज़र नहीं आती
  • लंबे समय से उठाए जा रहे कुछ मुद्दों पर भी हाल में बड़ी संख्या में issues बंद कर दिए गए, जिससे community में नाराज़गी हुई

विकल्प

  • इन समस्याओं और GitHub की सुधार की कमी को देखते हुए, GitHub Actions अपनाने से पहले सावधानी से सोचना ज़रूरी है
  • बाजार में GitLab, Jenkins, TeamCity जैसे कई दूसरे CI/CD options उपलब्ध हैं
  • Dagger जैसे tools, जो नया approach पेश करते हैं, उन्हें भी परखने लायक माना जा सकता है

संबंधित पढ़ाई

6 टिप्पणियां

 
bichi 2025-02-03

CI/CD में GitLab सबसे बढ़िया है
 
devsepnine 2025-01-24

मैं भी GitLab इस्तेमाल करता था, लेकिन जब GitHub Actions के माहौल में आया था तो याद है कि लगा था कि यहाँ कुछ भी ठीक से काम नहीं करता...
 
jjpark78 2025-01-23

GitHub में repositories को group के हिसाब से बाँधकर manage नहीं कर पाना भी मेरी बड़ी शिकायतों में से एक है..
 
jjpark78 2025-01-23

पाइपलाइन के मामले में GitLab वाकई बहुत अच्छा लगता है। ऊपर बताई गई बातें GitLab में सब हो जाती हैं।
Monorepo होने पर यह सेट करना भी आसान है कि किस फ़ोल्डर में बदलाव होने पर कौन-कौन से टेस्ट या क्या-क्या रन होना चाहिए।
 
tujuc 2025-01-22

इसके लिए GitHub Actions का इतिहास जानना ज़रूरी है...

शुरुआती GitHub Actions का रूप आज की स्थिति से अलग था...
ओपन होने से लगभग 6 महीने पहले (याद थोड़ा धुंधला है) GitHub का अधिग्रहण MS ने किया था, और लगता है कि Actions का विकास MS में Azure DevOps टीम के साथ मिलकर करने का फैसला हुआ था।
उस समय Azure DevOps में नए features आना लगभग बंद हो गए थे, और Azure DevOps में मौजूद features के नए updates GitHub Actions में आ रहे थे...
उसी समय यह Yaml में बदला गया था और आज वाला environment बना था.... दुखभरा चेहरा

उसके बाद से ऐसा लगता है कि developers वापस अपनी-अपनी टीमों में चले गए और फिर इस पर ज़्यादा काम नहीं हो पाया...
अफसोस है...
हमारी कंपनी में अभी GitHub Actions आधारित CI/CD सेटअप बना हुआ है... अभी तक कोई खास कमी महसूस नहीं हुई, इसलिए इस्तेमाल कर रहे हैं...

लगता है इस पर नज़र बनाए रखनी पड़ेगी...
 
GN⁺ 2025-01-22
Hacker News राय

  • पाइपलाइन DSL में वास्तविक लॉजिक शामिल नहीं होना चाहिए; इसका उपयोग सिर्फ़ कामों को orchestrate करने के लिए होना चाहिए। जटिल कामों को script के रूप में बनाकर आसानी से चलाने योग्य रखना चाहिए। इससे GitHub Actions, Jenkins, Azure DevOps आदि में वही काम आसानी से किए जा सकते हैं

  • GitHub Actions सेट करते समय prebuilt actions से बचना और इसे एक साधारण shell runner की तरह इस्तेमाल करना बेहतर है। Python, Ruby, Bash आदि में script लिखकर उसे GitHub Action में चलाने से local testing आसान हो जाती है और बेवजह की परेशानियाँ कम होती हैं

  • GitHub Actions को इस तरह सेट किया जा सकता है कि checks सिर्फ़ तब चलें जब कुछ शर्तें पूरी हों। लेकिन ऐसे नियमों का उपयोग करने पर "Pull request और required checks" वाली समस्या सामने आती है। बाहरी services के साथ इस्तेमाल होने पर required checks का पास होना अनिवार्य होता है, नहीं तो merge नहीं किया जा सकता

  • 'Pull request और required checks' समस्या का एक समाधान यह है कि हर required check workflow का एक 'no op' version बनाया जाए, ताकि शर्तें पूरी न होने पर वही चले और code 0 के साथ exit कर जाए। यह मूल रूप से उपलब्ध सुविधा है, लेकिन समाधान थोड़ा जटिल है

  • Travis CI local में CI test करने के लिए शानदार था। GitHub Actions को GitLab CI से प्रतिस्पर्धा करने के लिए बनाया गया था, और यह enterprise market में हिस्सेदारी खो रहा था

  • Buildkite आज़माने की सिफारिश की जाती है। अगर आप GitHub Actions से आगे बढ़ना चाहते हैं, तो Buildkite एक अच्छा विकल्प हो सकता है। बड़े अमेरिकी tech companies में इसका उपयोग करने का अनुभव रहा है, और CI का यही एकमात्र सुखद हिस्सा था

  • GitHub Actions की architecture ऐसी है कि यह गलत security decisions लेने की ओर ले जा सकती है। उदाहरण के लिए, organization या repository secrets सुविधाजनक होते हैं, लेकिन वे security vulnerability भी बन सकते हैं। repository environments में अलग secrets हो सकते हैं, लेकिन यह सुनिश्चित करना ज़रूरी है कि सही workflow सिर्फ़ सही environment तक ही पहुँच सके

  • CI systems का सामान्य दर्शन ही गलत है। CI को code चलाने के बजाय, code को CI चलाना चाहिए। CI को API उपलब्ध करानी चाहिए ताकि उपयोगकर्ता system को जानकारी दे सकें

  • Bazel का उपयोग करके CI tool से Bazel targets build करवाए जा सकते हैं, और ज़रूरत पड़ने पर remote build execution के ज़रिए parallelism बढ़ाया जा सकता है। यह लगभग 10M+ lines of code या बहुत बड़े services के लिए उपयुक्त है

  • GitHub में "required checks" तय किए जा सकते हैं, और उनका हमेशा green रहना ज़रूरी होता है। लेकिन अगर वे सिर्फ़ किसी खास folder में बदलाव होने पर ही चलते हैं, तो दूसरे folders में बदलाव होने पर merge नहीं हो पाता। अगर सारे tests नहीं चलेंगे तो integration का मतलब ही नहीं रह जाएगा, इसलिए tests को तेज़ी से चलने लायक बनाना चाहिए