Garnix बंद किया जा रहा है

• garnix Shopify के साथ जुड़ने की प्रक्रिया के तहत अपनी होस्टिंग सेवा 15 जुलाई 2026 को बंद करेगा
• garnix codebase को open source के रूप में जारी किया जाएगा, ताकि उपयोगकर्ता अपने स्वयं के instance या shared instance पर migrate कर सकें
• जो उपयोगकर्ता सार्वजनिक community instance चलाने में रुचि रखते हैं, वे garnix टीम से संपर्क कर सकते हैं, और टीम भी इस बारे में बातचीत चाहती है
• 15 जुलाई 2026 को सभी user data हटा दिए जाएंगे, और इसमें build artifacts भी शामिल होंगे
• जिन data और build artifacts को सुरक्षित रखना है, उन्हें बंद होने की तारीख से पहले स्वयं डाउनलोड करना होगा, और मौजूदा सूचना ईमेल उद्धरण के रूप में साझा की गई है

---

सेवा बंद होना और code जारी करना

• garnix Shopify के साथ जुड़ रहा है, और इस transition के हिस्से के रूप में होस्टेड garnix सेवा 15 जुलाई 2026 को बंद की जाएगी
• garnix codebase को open source के रूप में जारी किया जाएगा ताकि उपयोगकर्ता अपने स्वयं के instance या shared instance पर जा सकें
• जो उपयोगकर्ता सार्वजनिक community instance चलाने में रुचि रखते हैं, वे garnix टीम से संपर्क कर सकते हैं

user data और migration की तैयारी

• 15 जुलाई 2026 को सभी user data हटा दिए जाएंगे, और इसमें build artifacts भी शामिल होंगे
• जिस data या build artifacts को सुरक्षित रखना है, उसे बंद होने की तारीख से पहले स्वयं डाउनलोड करना होगा
• बंद होने की सूचना garnix.io पर पुष्टि नहीं हुई थी, और इसे [e-mail] से प्राप्त ईमेल की सामग्री उद्धृत करते हुए साझा किया गया था
• garnix टीम ने Open Collective के समय से मिले दान और feedback सहित community support के लिए आभार जताया, और टीम के सदस्य Alex David, Sönke Hahn, Julian K. Arni बताए गए हैं

[GN⁺]

Lobste.rs की राय

• अफ़सोस है! rolling deployment की समस्या सुलझाने के लिए service dependency URL को service build में एम्बेड करने वाला लेख मुझे सच में बहुत पसंद था
  https://garnix.io/blog/call-by-hash/

• जिन्हें यह जानना है कि Garnix क्या है:
  Garnix, Nix-ified flake-आधारित GitHub repositories के लिए एक CI service है
  स्रोत: https://github.com/garnix-io/garnix-ci#garnix

• मैंने अब तक जितने भी CI systems इस्तेमाल किए हैं, उनमें Garnix बहुत ही आगे था
  जब GitHub Actions अभी भी runner ढूंढ रहा होता था, तब तक Garnix build पूरा कर चुका होता था, और मेरे मध्यम-जटिल Rust project भी आम तौर पर 1 मिनट के अंदर खत्म हो जाते थे
  जब केवल docs बदले होते थे, तब यह और भी तेज़ होता था, और docs को सच में build भी किया जाता था
  बेशक इसमें Nix का योगदान है, लेकिन Garnix ने उस integration को वाकई बहुत अच्छी तरह किया था
  build system के साथ integrated CI, हर बार S3 से filesystem के आधे हिस्से जितना tar डाउनलोड करके cache जोड़ने वाले तरीके से कहीं बेहतर काम कर सकता है
  ऊपर से Nix-आधारित होने की वजह से यह local build के बिल्कुल वही चीज़ build करता है, इसलिए “yaml की टाइपो ठीक करो, push करो, 10 मिनट इंतज़ार करो, अगली error देखो, debug output जोड़ो, फिर से push करो...” जैसे लंबे feedback loop नहीं होते
  अगर local में build हो जाता है, तो CI में भी काम करता है

• दुख की बात है। पिछले करीब एक हफ्ते में कुछ अजीब समस्याएँ दिखी थीं, लेकिन मैंने उन्हें ज़्यादा गंभीरता से नहीं लिया
  सिर्फ GitHub support होना थोड़ी शिकायत वाली बात थी, फिर भी यह एक शानदार service थी
  इस वीकेंड मैं open source version देखूँगा और समझने की कोशिश करूँगा कि self-hosting व्यावहारिक है या नहीं, और अगर किसी के पास Nix build alternatives हों तो बताना अच्छा रहेगा

• लॉन्च के समय से ही garnix इस्तेमाल कर रहा हूँ, इसलिए इसका बंद होना काफ़ी अफ़सोसजनक है
  अगर किसी को Nix CI या self-hostable समाधान पता हो तो बताना अच्छा रहेगा
  मैं garnix को ज़्यादातर cache की तरह इस्तेमाल करता था, और public check status के आधार पर auto-merge workflow भी बनाया हुआ था

  • tangled.org जल्द ही कुछ ऐसा ही जारी करने वाला है। Self-hosting भी संभव होनी चाहिए
  • लगता है garnix open source हो रहा है, इसलिए यह self-hosting के लिए एक उम्मीदवार बन सकता है
    मैं ग्राहक नहीं था और घर पर ही Nix इस्तेमाल करता हूँ, लेकिन self-host करने का तरीका ज़रूर देखूँगा

• अगर आगे यह हिस्सा न होता, तो यह पूरी तरह topic से बाहर होता:
  “लेकिन हम garnix codebase को open source के रूप में जारी कर रहे हैं, और उसे यहाँ देखा जा सकता है”
  मेरे हिसाब से यह हिस्सा topic के अनुरूप और दिलचस्प है
  हमारी कंपनी Nix में पूरी तरह निवेश कर रही है, इसलिए भावनाएँ काफ़ी मिश्रित हैं
  नकारात्मक भावना का बड़ा हिस्सा इस बात से आता है कि Nix सच में शानदार तकनीक है, लेकिन अब भी किसी बहुत युवा एलियन अवशेष जैसी महसूस होती है
  Nix में इतने सारे दिलचस्प और मूल्यवान काम अभी बाकी हैं कि उसे लेकर उत्साह बना रहता है
  Nix अपनाने का मतलब है कि मौजूदा platforms ने लंबे समय में जो बहुत-सी सुविधाजनक चीज़ें बनाई हैं, उनमें से काफ़ी कुछ छोड़ना पड़ता है, इसलिए मैं Garnix समेत Nix ecosystem के कई tools देख रहा था
  वास्तव में हमारी कंपनी उन “basic” features पर काफ़ी ज़्यादा मेहनत कर रही है, जो सामान्यतः मुफ्त में मिल जाते
  उदाहरण के लिए GitHub Actions में validation चलाना भी आम project की तुलना में अधिक जटिल है, और caching तथा parallelization जैसी चीज़ें मज़बूत और तेज़ build के लिए बहुत महत्वपूर्ण हैं
  लगता है कि Nix ecosystem को आगे बढ़ाने वाली कंपनियाँ काफ़ी बड़ी होंगी, या कोई Nix giants के shoulders पर खड़े होकर दुनिया हिला देने वाली कोई चीज़ बनाएगा
  अफ़सोस की बात है कि Garnix उन शुरुआती अग्रदूतों में से एक लगता है जिन्हें किसी बड़े संगठन ने अपने में समा लिया

  • मज़ेदार बात यह है कि Nix उतना नया भी नहीं है
    यह Docker से कुछ साल पहले आया था, बस यह देर से खिलने वाली तकनीक थी, इसलिए हाल में लोकप्रिय हुआ

• अब जबकि garnix open source हो गया है, मैं सोच रहा हूँ कि इसे GitHub से अलग करना कितना मुश्किल होगा
  flake से अलग करना तो काफ़ी आसान होना चाहिए। flake असली नहीं है और आपको नुकसान नहीं पहुँचा सकता

  • जब भी मैं garnix को देखता था, तो खिड़की के बाहर SpongeBob और Patrick को मज़े करते देख कर जलते हुए Squidward जैसा महसूस करता था
    यह संभावना निश्चित रूप से रोमांचक है

• थोड़ा topic hijack करूँ तो, मैं CI को Nix पर ले जाने की कोशिश कर रहा हूँ, लेकिन dev/CI environment बहुत बड़ा है
  मुख्य कारण यह है कि उसमें कई पूरे browsers शामिल हैं, और मुझे nix build या cache restore से बचने का कोई तरीका नहीं मिल रहा
  1Gbit environment में 10GB restore करना भी बहुत धीमा है
  Docker में self-hosted runners इस्तेमाल करने पर यह समस्या हल हो जाती है
  आप Docker image बना लेते हैं और उसे उस host पर cache के रूप में बनाए रखते हैं जहाँ CI runner चलता है
  लेकिन Nix में यह कैसे किया जाता है, मुझे समझ नहीं आता
  मुझे ऐसा तरीका चाहिए जिससे nix store साझा किया जा सके जिसमें dev environment के लिए ज़रूरी सब कुछ पहले से मौजूद हो, और वह repository में check-in किए गए असली dev environment flake से derived हो
  क्या ऐसा कुछ मौजूद नहीं है?

  • मैं ठीक से समझ नहीं पा रहा हूँ। अगर आप runner खुद host करते हैं और उस workflow के लिए ज़रूरी चीज़ों से /nix/store पहले से भर देते हैं, तो OCI image की तरह वह बस वहीं मौजूद नहीं होगी क्या?
    अपनी पिछली नौकरी में हम self-hosted GitLab runners चलाते थे, और service में लगाने से पहले हाल के build artifacts के सेट को instantiate करके पहले से warm कर देते थे
    फिर jobs /nix/store में cached चीज़ों का वैसा ही इस्तेमाल कर लेती थीं