- 一部のプロジェクトを GitHubからCodebergへ移しながら、最小限の労力で移行を始める方法を整理
- Codeberg の リポジトリ import 機能 により、Issue・PR・リリースまで含めた完全な移行が可能で、UI とワークフローは GitHub と似ている
- 静的ページホスティング は
codeberg.page で代替でき、grebedoc.dev や statichost.eu のような代替手段も存在
- 最大の難所は CI 環境の構築 で、GitHub の macOS ランナーと無料実行枠を手放す必要があるが、Forgejo Actions や Woodpecker CI で代替可能
- 移行後は GitHub リポジトリを 読み取り専用アーカイブとして維持したりミラーリング したりして、オープンソースエコシステムとのつながりを完全には断たない方法が示されている
GitHubからCodebergへの移行プロセス
- 一部のリポジトリを GitHubからCodebergへ移行 し始めた経験をもとに、実際のマイグレーション作業の難易度と使い勝手を説明
- Codeberg はまだ十分に整っていないと思って先延ばしにしていたが、プロジェクトによっては移行が意外なほど簡単なこともある
- 目標は完璧な設定ではなく、最も簡単に移行を始める方法 を見つけることにある
-
リポジトリと Issue の移行
- Codeberg は GitHub リポジトリの import 機能を提供しており、Issue・PR・リリースとそのアーティファクトも一緒に移行できる
- この過程で Issue 番号、ラベル、作成者情報 がそのまま維持される
- Codeberg の UI は GitHub とほぼ同じで、他の Issue トラッカーから GitHub に移すときに必要な複雑な手順よりも、はるかに簡単な体験を提供する
-
静的ページホスティング
- GitHub Pages を使っていた場合は codeberg.page を代替として利用できる
- 公式な 可用性保証（SLO） はないが、実際にはダウンタイムを経験していないと述べている
- HTML をブランチに push する方式で、GitHub Pages に似た構造
- 代替として grebedoc.dev や statichost.eu も利用可能
-
CI（継続的インテグレーション）環境の難しさ
- マイグレーションで最も厄介なのは CI 環境の構築
- GitHub は 無料の macOS ランナー と 公開リポジトリ向けの無制限実行枠 を提供するが、Codeberg ではそれを諦める必要がある
- 解決策として 言語ごとのクロスコンパイル と Forgejo Actions ランナーのセルフホスティング を活用できる
-
Forgejo Actions vs Woodpecker CI
- Codeberg では Woodpecker CI のほうが安定している が、Forgejo Actions は GitHub Actions ユーザーにとってよりなじみやすい環境を提供する
- UI と YAML 構文がほぼ同一 で、既存の GitHub Actions ワークフローの多くがそのまま動作する
- 例として、GitHub Actions で
uses: dtolnay/rust-toolchain を使っていた部分は、Forgejo Actions では uses: https://github.com/dtolnay/rust-toolchain に変更すればよい
- 現在の Codeberg の Forgejo Actions ドキュメントは 最新ではなく、関連する PR が存在する
-
macOS ランナーが必要な場合
- macOS ビルドがどうしても必要なら、GitHub Actions を引き続き使い、Codeberg リポジトリから GitHub へコミットをミラーリングする方法がある
- Forgejo Actions が GitHub API をポーリングして CI 状態を Codeberg に同期 するよう設定できる
- 他の macOS ビルドを提供する CI サービスも試したが、Codeberg との統合は GitHub Actions ほど単純ではなかった
-
GitHub リポジトリの扱い方
- 移行後、GitHub リポジトリは README を修正してアーカイブ化 する
- Codeberg から GitHub へコミットを push する設定も可能だが、その場合でもユーザーは引き続き PR の作成や Issue コメント ができてしまう
- 一部では GitHub リポジトリの Issue 機能を無効化 するが、この場合はすべての Issue が 404 で消え、PR は無効化できない
- 例として
libvirt/libvirt リポジトリは、すべての PR を自動で閉じる GitHub Action を使っている
- このようなアプローチは セルフホスティングやオープンソースエコシステム全体に悪影響 を与える可能性がある
- ユーザーがビルド最適化やリリースファイルのダウンロード頻度改善に取り組む動機を失う可能性がある
- 移行期間中は 読み取り専用ミラーの維持 や GitHub Pages・Actions の併用 も検討できる
1件のコメント
Hacker Newsのコメント
Codeberg自体は嫌いではないが、GitHubの完全な代替ではない
個人用コードリポジトリや実験用スクリプトを置くには制約が多く、プライベートリポジトリは100MBに制限されている
GitHub Pagesのようにホームページをホスティングすることもできない。こうした用途なら自分で Forgejo をセルフホスティングするほうが現実的な代替になる
関連内容は Codeberg FAQ によく整理されている
私がOSSプロジェクトをGitHubに置く理由は単純で、コミュニティがそこにいるから だ
コードだけ置ければいいなら、SSHやSFTPで直接ホスティングする
私は自分の 個人Giteaインスタンス にしか置かず、スターや宣伝は気にしていない
私は Forgejoのセルフホスティング で個人プロジェクトをすべて管理している。GitHubが恋しくなることはまったくない
Tailscaleでアクセスを制限して AIクローラーの遮断 もできる
今後はGitHub代替を評価することがますます重要になりそうだ
ただ、GitHubが CIとマルチアーキテクチャビルドの標準 を作ってしまったので、コミュニティ主導の代替が競争しにくい
GitHubは多くを「無料」で提供しているが、その代償として データ収集や学習 に利用される可能性が高い
Codebergはプライベートリポジトリをサポートしていないので、Copilotが公開リポジトリをかき集めるのを防ぐこともできない
Codeberg FAQ によれば、プライベートプロジェクトが必要なら Forgejoのセルフホスティング を推奨している
私たちの会社はGitHubから GitLabのセルフホスティング に完全移行した
Tailscaleの背後に置いているのでSSOの負担がなく、CIランナーはEKSとGPUクラスターで動かしている。同じような移行を考えている人の助けになれると思う
単に「GitHubを置き換えよう」と言うだけでは意味がない。新しい習慣と価値提案 が必要だ
GitHubがSourceForgeを置き換えたように、次世代のプラットフォームは コード作成とコラボレーションをリアルタイムで結びつける 必要がある
たとえばGoogle Docsのように プロンプトごとにコミットが生成される構造 になるかもしれない
Codebergは理想的だが、現実には 安定性の問題 が大きい
Cloudflareなしで運営しているため DDoS攻撃 に弱く、ダウンタイムも多い。開発中にリモートリポジトリへアクセスできないと本当につらい
Microsoftによる買収以降、GitHubはほとんど使っていない。Sourcehut のシンプルなメールベースのワークフローのほうがむしろ気に入っている
CIも単に ローカルで実行可能なコマンドベース で十分だと思う
コードリポジトリは本質的に 分散・連合型の構造 であるべきだ
gitの 暗号学的署名体系（GPG/SSH） によって、リポジトリの信頼とコミットの信頼を分離できる
中央にはキーレジストリとネームスペース管理だけを置き、残りは分散させればいい