
2026/03/26 22:38
GitHub から Codeberg への移行 ― 怠け者のために
RSS: https://news.ycombinator.com/rss
要約▶
Japanese Translation:
要約
GitHub から Codeberg にリポジトリを移行する場合、Codeberg のインポートツールを使用すると、Issue 番号・ラベル・作成者情報を保持したままスムーズに移行できます。プラットフォームは
codeberg.page という Pages ライクなサービスも提供しており、代替として grebedoc.dev や statichost.eu などがあります。
Codeberg 上での CI 統合は、無料の macOS ランナーが利用できず、無制限容量も提供されないため、より複雑です。推奨される解決策としては、クロスコンパイルや Forgejo Actions を実行するセルフホストランナーを使用することがあります。Forgejo Actions は、UI が馴染みやすく YAML 構文とアクションエコシステムが整っているため、Woodpecker CI よりも好まれます。
macOS ビルドが不可欠な場合は、元のリポジトリで GitHub Actions を継続使用し、コミットを Codeberg にミラーリングしつつ、Forgejo Actions から GitHub の API をポーリングして CI ステータスを Codeberg に同期させることができます。移行後は、古い GitHub リポジトリをアーカイブするか、読み取り専用のミラーとして保持し、新しいコミットも必要に応じて再度ミラーリングできます。
GitHub 上で Issue を無効化して重複議論を避けることは破壊的で 404 エラーを引き起こします(プルリクエストの同様の無効化はできません)。一部プロジェクト(例:
libvirt/libvirt)では、移行中に GitHub Action を使ってプルリクエストの自動閉鎖を実装しています。最後に、セルフホスティング CI はビルド最適化を阻害し、プロジェクトサイトからリリース tarball を頻繁にダウンロードする必要が減るため、保守ワークフローに影響を与える可能性があります。本文
2025‑09‑06
GitHub から Codeberg へのリポジトリ移行を始めたばかりです。ずっとやりたいと思っていたのですが、Codeberg がまだ準備不足だと感じており、移行プロセスが面倒(退屈)だと考えていたため、先延ばしにしていました。
実際にはそれは一部だけで、プロジェクトによって大きく変わります。もし私の状況と似た立場にいるなら、このメモが動機付けや出発点になることを願っています。これらの解決策は長期的に残るものではなく、GitHub から移行する際に最も手軽に始められる方法を想定しています。
-
Issue・Pull Request・Release の移行
最も簡単な部分です:Codeberg は GitHub からのリポジトリインポート機能を提供しており、Issue 番号・ラベル・作者情報をそのまま保持します。UI は GitHub にほぼ同じで、他のトラッカーから GitHub へ移行する際に使われていた不便なハックよりもずっとスムーズです。 -
GitHub Pages
GitHub Pages を利用している場合は
を使えます。稼働時間保証(SLO)がないという警告がありますが、実際にはダウンタイムを感じていませんし、現時点では問題ありません。HTML はブランチにプッシュするだけで、旧 GitHub Pages と同様です。codeberg.page -
継続的インテグレーション(CI)
最も難しい部分は CI です。GitHub は無料の macOS ランナーと公開リポジトリ向け無制限容量を提供しており、非常に魅力的です。しかし、これらを放棄する必要があります。- プログラミング言語ごとのクロスコンパイルを検討し、Forgejo Actions 用のセルフホストランナーでそれぞれ解決します。
- Forgejo Actions を Woodpecker CI にせず選ぶ理由
Woodpecker は Codeberg 上では安定していますが、Forgejo Actions のドキュメントは現在古くなっています。対照的に Forgejo Actions は GitHub Actions 来歴者には非常に馴染みやすいです:UI と YAML 構文がほぼ同じで、既存のアクションエコシステムも Codeberg 上でほぼそのまま動作します。 - macOS ランナーが絶対必要な場合は、GitHub リポジトリに GitHub Actions を残し、Codeberg のコミットをすべて GitHub にミラーリングして、Forgejo Actions が GitHub API をポーリングし CI ステータスを Codeberg に同期させる方法をおすすめします。
(まだ試したことはありませんが、macOS ビルドを提供する他の CI プロバイダーも試しましたが、GitHub Actions ほど簡単に統合できるとは思いませんでした。)
-
古い GitHub リポジトリの扱い
- README を更新し、リポジトリをアーカイブしました。
- Codeberg に新しいコミットをプッシュするよう設定すれば、ユーザーは引き続き PR を作成したり Issue やコミットにコメントできるようになります。
- 一部の人は GitHub リポジトリで Issue を無効化しますが、それは破壊的行為です。Issue は 404 になり、PR を無効化することはできません。
のように、GitHub Action が自動ですべての PR をクローズするリポジトリもあります。libvirt/libvirt
-
その他の考慮点
この設定にはセルフホスティングや広範なソフトウェアエコシステムへの悪影響があります。ビルド最適化やリリース tarball のダウンロード頻度を促進するインセンティブが無くなるからです。
移行期間中は読み取り専用ミラーを維持したり、GitHub Pages と GitHub Actions を継続利用することも検討してください。