Git hooks और nq से बना न्यूनतम CI

 (mccd.space)
1 पॉइंट द्वारा GN⁺ 9 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • व्यक्तिगत सर्वर के bare Git repository में post-receive hook जोड़कर test, build और file move को ऑटोमेट करने वाला एक सरल CI सेटअप है
  • मौजूदा CI में जटिल YAML configuration, धीमा execution और कठिन self-hosting जैसी बातें थीं, जबकि यहाँ पूर्ण build isolation या secret management तक की ज़रूरत नहीं थी
  • अगर hook में काम सीधे चलाया जाए तो failure पर push reject हो सकता है या completion में देरी हो सकती है, इसलिए न्यूनतम job queue nq से इसे background में प्रोसेस किया जाता है
  • hook केवल nq को call करता है और logs को ssh server nqtail -a से देखा जा सकता है, इसलिए इसे तेज़ और सरल तरीके से चलाया जा सकता है
  • ज़रूरत के अनुसार landdown·Podman से build को isolate किया जा सकता है, sops से secrets manage किए जा सकते हैं, या Git email patch·git-shell·git http-backend से development workflow को बढ़ाया जा सकता है

post-receive hook और nq सेटअप

  • व्यक्तिगत सर्वर पर ssh server git init --bare repo से repository बनाई जाती है और git clone server:repo से clone किया जाता है
  • bare repository की hooks directory में shell script के रूप में post-receive hook रखा जाता है, जो हर push पर CI शुरू करता है
  • अगर काम hook में सीधे चलाया जाए तो दो समस्याएँ आती हैं
    • script fail होने पर push reject हो जाता है
    • script धीमी हो तो push पूरा होने में भी देरी होती है
  • hook में न्यूनतम job queue nq को call करके काम को background queue में जोड़ा जाता है
    • logs को ssh server nqtail -a से देखा जाता है
    • setup process एक छोटे tutorial में देखी जा सकती है

isolation और development workflow का विस्तार

  • build को sandbox में चलाने के लिए landdown का उपयोग किया जा सकता है
  • Podman से build को host environment से isolate किया जा सकता है या sops से secrets manage किए जा सकते हैं
  • bazaar शैली के development के लिए email से Git patch लेने वाला setup उपयुक्त है
  • cathedral शैली का development git-shell या git http-backend से configure किया जा सकता है

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

1 टिप्पणियां

 
GN⁺ 9 시간 전
Lobste.rs की टिप्पणियां

  • CI में कम-से-कम दो समस्याएं होती हैं
    आसान समस्या है code change होने पर make test चलाना, और कठिन समस्या है Linux, Windows, Mac तीनों पर make test चलाना

    • Linux आसान है और Windows कठिन, लेकिन macOS तो दर्दनाक स्तर का है
    • CI में कठिन हिस्सा, मेरे हिसाब से, fail होने पर debugging तक सपोर्ट करने वाला job execution engine है
      मौजूदा engines के developer experience और debugging features हमेशा पीछे रह जाते हैं, इससे असंतोष है, इसलिए https://ci.pico.sh पर CI system बना रहा हूं। DSL भी पसंद नहीं, और hierarchical YAML ऐसा लगता है जैसे धीरे-धीरे जान निकाल रहा हो
    • यह तरीका आसान समस्या हल करता है, और QEMU से BSD परिवार को support कर सकता है तथा Docker से कई distributions तक expand किया जा सकता है, लेकिन उससे आगे के लिए अधिक complete tool चाहिए लगता है

  • इसे gitolite के ऊपर बनाया था और Temporal को भेजकर build process को बिना सीमा control किया था
    execution fail होने पर push reject भी किया जा सकता है, लेकिन आम तौर पर hook को pass होने देने के बाद failure को अलग से handle करते हैं; setup भी सरल और मजेदार था

    • gitolite के access control tools खास तौर पर पसंद आए, और non-existent repository पर push करके नई repository बनाने का तरीका भी शानदार है

  • shell script execution पर केंद्रित एक और minimal CI laminar CI है, जिसमें web UI भी मिलता है

  • काफी पहले Windows-only enterprise environment में पूरी team के इस्तेमाल के लिए local CI server के रूप में Mac mini रखा था और iOS app build किया था; यह शुरुआती दौर में आजमाए गए Git usage तरीकों में से एक था

  • यह https://mccd.space/git/ पर मिला, लगता है stagit fork इस्तेमाल हो रहा है
    कुछ महीने पहले तक Forgejo और Woodpecker चला रहा था, लेकिन उनमें ज्यादातर features की जरूरत नहीं थी, इसलिए सब हटाकर इसी जैसा हल्का setup खोज रहा था। अगला काम CI था, इसलिए timing सही है, और जल्द release करने वाली एक छोटी library को SourceHut पर mirror करना है या नहीं, इस पर सोच रहा हूं

    • stagit को fork करके contact email और navigation bar जोड़ा, CSS changes के लिए ID डाली, और गैर-जरूरी जानकारी हटाई
      repositories को git-daemon के जरिए web पर read-only public किया है, और पूरा setup कैसे करना है, यह यहां लिख रखा है

  • इस लेख से nq के बारे में पहली बार पता चला, लेकिन शायद systemd-run इस्तेमाल करूंगा
    लगभग सभी runners पर Nix इस्तेमाल कर रहा हूं, इसलिए अगर nix flake check के results को OTLP metrics और logs के रूप में expose करूं, तो CI requirements को monitoring system से पूरा किया जा सकता है लगता है

  • इतना simple self-hosted development platform setup पसंद आया
    CI के लिए हल्का और simple container system bubblewrap आसानी से configure करके इस्तेमाल किया जा सकता है। हालांकि nq इस्तेमाल करने पर CI fail होने पर push reject करना संभव नहीं लगता; यह कैसे handle करते हैं, जानना चाहूंगा

    • scripts को restrict करने के लिए Landlock इस्तेमाल करने वाला helper tool भी है, और usage थोड़ा अधिक simple लगता है
      अगर ज्यादा isolation चाहिए तो Podman, Docker, bubblewrap जोड़ सकते हैं। जिस वजह से tests चलाने वाला pre-commit hook नहीं रखते, उसी वजह से CI fail होने पर push reject नहीं करता: कभी-कभी broken काम भी commit या push करना पड़ता है, और push बहुत slow हो सकता है। अगर reject जरूरी हो तो nq के बिना CI को synchronously चलाकर exit code 0 न होने पर push रोक दें
      या फिर main के अलावा branches को nq से चलाएं और सिर्फ main branch को synchronously चला सकते हैं

  • landdown link टूटा हुआ लगता है