GitHub Actions की वजह से होने वाली परेशानी

 (feldera.com)
2 पॉइंट द्वारा GN⁺ 2025-03-21 | 1 टिप्पणियां | WhatsApp पर शेयर करें

  • GitHub Actions की समस्याएँ

    • हाल ही में GitHub Actions में CI स्क्रिप्ट्स को दोबारा लिखने में बहुत समय लगा। पहले Earthly का उपयोग किया जाता था, लेकिन उसके बंद हो जाने के बाद फिर से GitHub Actions पर लौटना पड़ा।
    • CI जटिल है और इसमें merge queue, कई runners, Rust builds, Docker images, integration tests आदि शामिल हैं। हर PR merge पर काफी CI समय खर्च होता है।
    • अच्छे software practice के लिए ज़रूरी है कि सभी tests पास हों, मामूली गलतियाँ अपने-आप ठीक हो जाएँ, और जिन artifacts का test किया गया है वही release में भी हों। GitHub Actions यह संभव बनाता है, लेकिन इसकी configuration जटिल और असंगत है।

  • Status checks और merge queue

    • GitHub की merge queue, PR को main branch पर rebase करने के बाद CI चलाती है। लेकिन CI को queue में डालने से पहले और बाद में दोनों बार चलाना पड़ता है, और इसे configure करना कठिन है।
    • समाधान यह है कि दोनों चरणों में job name एक जैसा रखा जाए। इससे दोनों चरणों का पास होना आवश्यक हो जाता है।

  • सुरक्षा समस्याएँ

    • हाल ही में एक लोकप्रिय GitHub Action से छेड़छाड़ की गई। जवाबी उपाय के तौर पर dependencies को hash से pin करने की सलाह दी गई, लेकिन अधिकांश उपयोगकर्ता ऐसा नहीं करते।
    • GitHub का security model जटिल है और समझना कठिन है। आप GITHUB_TOKEN की default permissions सेट कर सकते हैं, लेकिन permissions हटाना स्पष्ट नहीं है।
    • Workflow permissions, action खुद पर निर्भर नहीं करतीं, और code के अंदर permissions बढ़ाना अजीब लगता है।

  • Docker और GitHub Actions का संयोजन

    • GitHub Actions में container के भीतर jobs चलाई जा सकती हैं, लेकिन file permissions की समस्या और $HOME directory की location बदल जाने जैसी दिक्कतें आती हैं।
    • container field में कई सीमाएँ हैं, इसलिए entrypoint override करना या सिर्फ कुछ steps को container के अंदर चलाना संभव नहीं है।

  • YAML में workflow development

    • YAML में logic लिखना जटिल हो सकता है और गलती करना आसान है। कुछ checks के लिए RustRover IDE का उपयोग किया गया, लेकिन बेहतर static checking की ज़रूरत है।
    • इसे local में test करना कठिन है, इसलिए एक जैसी repository बनाकर बार-बार commit और push करना पड़ता है, जब तक CI काम न करने लगे।
    • Workflows को छोटा रखा जाता है और artifacts push किए जाते हैं ताकि उन्हें दूसरे workflows में दोबारा इस्तेमाल किया जा सके। लेकिन artifacts download करते समय token की आवश्यकता होती है।

  • निष्कर्ष

    • नए CI scripts से merge समय काफ़ी कम हुआ है, लेकिन configuration प्रक्रिया जटिल है और debugging कठिन है। नवाचार की ज़रूरत है।

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

1 टिप्पणियां

 
GN⁺ 2025-03-21
Hacker News राय

  • कुछ लोगों का मानना है कि GitLab बेहतर है, लेकिन GitLab में भी अलग तरह की समस्याएँ हैं

    • कई CI टूल इस्तेमाल करने के बाद निष्कर्ष यह है कि जितना संभव हो उतना CI logic अपने ही code में लिखना महत्वपूर्ण है
    • इस बात में निवेश करना चाहिए कि pipeline को developer machine पर local रूप से चलाया जा सके
    • जहाँ तक संभव हो YAML के इस्तेमाल से बचना चाहिए
    • VC funding पाने वाले नए tools पर निर्भर नहीं होना चाहिए
    • जहाँ तक संभव हो self-hosted runner इस्तेमाल करने चाहिए और उन्हें on-premises पर चलाना चाहिए

  • यह दिलचस्प है कि GitHub Actions और DevOps की इतनी व्यापक आलोचना होती है

    • setup और test करना झंझटभरा हो सकता है, लेकिन एक बार चलने लगे तो उसे लगभग छूना नहीं पड़ता
    • Node version update के अलावा 4 साल में workflow में लगभग कोई बदलाव नहीं किया
    • व्यक्तिगत रूप से यह संतोषजनक लगता है

  • GitLab इस्तेमाल करने के बाद GitHub पर स्विच किया, लेकिन निराशा हुई

    • GitHub Actions, GitLab की तुलना में बहुत कमज़ोर लगा
    • अगर कंपनी चलानी हो तो GitLab चुनूँगा

  • 30-60 सेकंड का feedback loop सबसे खराब है

    • GHA environment को local में reproduce करने की कोशिश की, लेकिन यह संभव नहीं था
    • छोटी-सी गलती की वजह से बहुत समय बर्बाद होता है

  • यह नहीं चाहता कि CI अपने-आप code को modify करे

    • मामूली checks को pre-commit hook के रूप में चलना चाहिए

  • यह देखकर निराशा होती है कि GitHub Actions का विकास जैसे रुक गया है

    • Earthly और Dagger का development रुक जाना अफसोसजनक है
    • Depot.dev का मूल्यांकन करने पर लगा कि बहुत होशियार टीम ने इस समस्या को अच्छी तरह हल किया है

  • GitHub Actions की वजह से container को install script की तरह गलत तरीके से इस्तेमाल किया जाता है

    • workflow में काफी समय installer चलाने में खर्च हो जाता है

  • सही tool चुनना महत्वपूर्ण है

    • GitHub Actions सरल कामों के लिए उपयुक्त है, लेकिन जटिल कामों के लिए नहीं

  • GitHub Action की security समस्याओं के कारण hash का इस्तेमाल करके dependencies को pin करना चाहिए

    • hash इस्तेमाल करने से यह काफी ज़्यादा सुरक्षित हो जाता है

  • GitHub Actions में कई समस्याएँ हैं

    • 10GB cache limit, runner type के अनुसार concurrency limit, ऊँची लागत आदि
    • Depot.dev, GitHub Actions को तेज़ बनाने और उसकी समस्याएँ हल करने की कोशिश कर रहा है
    • Docker image build को तेज़ करके और runner को optimize करके काम को बहुत तेज़ बनाता है
    • GitHub Actions लोकप्रिय है, लेकिन उसमें सुधार की काफी गुंजाइश है