• कुछ प्रोजेक्ट्स को GitHub से Codeberg पर ले जाते हुए, कम-से-कम मेहनत में माइग्रेशन शुरू करने का तरीका संक्षेप में बताया गया है
  • Codeberg की repository import feature के जरिए issues, PRs, और releases समेत पूरा माइग्रेशन संभव है, और UI तथा workflow, GitHub से मिलते-जुलते हैं
  • static page hosting के लिए codeberg.page का विकल्प इस्तेमाल किया जा सकता है, और grebedoc.dev या statichost.eu जैसे विकल्प भी मौजूद हैं
  • सबसे बड़ी कठिनाई CI environment सेटअप है, क्योंकि GitHub के macOS runners और free execution quota को छोड़ना पड़ता है; इसके बदले Forgejo Actions या Woodpecker CI इस्तेमाल किए जा सकते हैं
  • माइग्रेशन के बाद GitHub repository को read-only archive की तरह रखा जा सकता है या mirror किया जा सकता है, ताकि open source ecosystem से जुड़ाव पूरी तरह न टूटे

GitHub से Codeberg पर माइग्रेशन की प्रक्रिया

  • कुछ repositories को GitHub से Codeberg पर माइग्रेट करना शुरू करने के अनुभव के आधार पर, वास्तविक migration process की कठिनाई और सुविधा का वर्णन किया गया है
    • अब तक यह सोचकर टालते रहे कि Codeberg अभी पर्याप्त रूप से तैयार नहीं है, लेकिन project के अनुसार migration उम्मीद से कहीं आसान हो सकता है
    • लक्ष्य एकदम परफेक्ट सेटअप नहीं, बल्कि माइग्रेशन शुरू करने का सबसे आसान तरीका ढूँढना है
  • repository और issue migration

    • Codeberg, GitHub repository import feature देता है, जिसके जरिए issues, PRs, releases और उनके artifacts भी साथ में माइग्रेट किए जा सकते हैं
      • इस प्रक्रिया में issue numbers, labels, और author information जस-का-तस बने रहते हैं
      • Codeberg का UI लगभग GitHub जैसा ही है, और किसी दूसरे issue tracker से GitHub पर जाने में लगने वाली जटिल प्रक्रिया की तुलना में यह कहीं अधिक सरल अनुभव देता है
  • static page hosting

    • अगर आप GitHub Pages इस्तेमाल कर रहे थे, तो उसके विकल्प के रूप में codeberg.page इस्तेमाल किया जा सकता है
      • आधिकारिक availability guarantee (SLO) नहीं है, लेकिन व्यवहार में downtime का अनुभव नहीं हुआ, ऐसा बताया गया है
      • HTML को branch में push करने के तरीके पर आधारित है, यानी GitHub Pages जैसी संरचना
      • विकल्प के तौर पर grebedoc.dev या statichost.eu भी इस्तेमाल किए जा सकते हैं
  • CI (continuous integration) environment की चुनौतियाँ

    • migration के दौरान सबसे मुश्किल हिस्सा CI environment सेटअप है
      • GitHub free macOS runners और public repositories के लिए unlimited execution quota देता है, लेकिन Codeberg पर यह छोड़ना पड़ता है
      • समाधान के रूप में language-specific cross compilation और Forgejo Actions runners की self-hosting का उपयोग किया जा सकता है
    • Forgejo Actions vs Woodpecker CI

      • Codeberg पर Woodpecker CI ज़्यादा स्थिर है, लेकिन Forgejo Actions, GitHub Actions उपयोगकर्ताओं के लिए अधिक परिचित अनुभव देता है
      • UI और YAML syntax लगभग एक जैसे हैं, और मौजूदा GitHub Actions workflows में से अधिकांश बिना बदलाव के चल जाते हैं
      • उदाहरण के लिए, GitHub Actions में uses: dtolnay/rust-toolchain इस्तेमाल किया गया हो, तो Forgejo Actions में उसे uses: https://github.com/dtolnay/rust-toolchain में बदलना होगा
      • फिलहाल Codeberg का Forgejo Actions documentation अप-टू-डेट नहीं है, और इस संबंध में एक PR मौजूद है
    • जब macOS runners की ज़रूरत हो

      • अगर macOS build वास्तव में ज़रूरी है, तो GitHub Actions का उपयोग जारी रखा जा सकता है, और Codeberg repository से GitHub पर commits mirror किए जा सकते हैं
      • Forgejo Actions को GitHub API poll करने और CI status को Codeberg के साथ sync करने के लिए कॉन्फ़िगर किया जा सकता है
      • macOS builds देने वाली दूसरी CI services भी आज़माई गईं, लेकिन Codeberg के साथ उनका integration, GitHub Actions जितना सरल नहीं था
  • GitHub repository को कैसे संभालें

    • migration के बाद GitHub repository में README बदलकर उसे archive किया जा सकता है
      • Codeberg से GitHub पर commits push करने के लिए सेटअप किया जा सकता है, लेकिन इस स्थिति में उपयोगकर्ता अब भी PR बना सकते हैं और issue comments छोड़ सकते हैं
      • कुछ लोग GitHub repository की issues feature disable कर देते हैं, लेकिन तब सभी issues 404 में गायब हो जाते हैं और PRs को disable नहीं किया जा सकता
      • उदाहरण के तौर पर libvirt/libvirt repository सभी PRs को अपने-आप बंद करने वाला GitHub Action इस्तेमाल करती है
    • इस तरह का तरीका self-hosting और पूरे open source ecosystem पर नकारात्मक असर डाल सकता है
      • उपयोगकर्ताओं की build optimization या release files download frequency सुधारने की प्रेरणा कम हो सकती है
      • संक्रमण काल में read-only mirror बनाए रखना या GitHub Pages और Actions को साथ में इस्तेमाल करना भी एक विकल्प हो सकता है

अभी कोई टिप्पणी नहीं है.

अभी कोई टिप्पणी नहीं है.