Cells: コントリビューション：フォーク
フォークワークフロー を使用すると、ユーザーは既存のプロジェクトのソースを任意の名前空間（個人またはグループ）にコピーできます。
1. 定義
フォークワークフロー はさまざまな使用パターンを持つ一般的なワークフローです：
- アップストリームプロジェクトへのコントリビューションを可能にします。
- リポジトリを個人の名前空間に保持します。
- ユーザーがプロジェクトをコピーして変更を加え、修正済みプロジェクトとしてリリースできます。
フォークにより、親プロジェクトへの書き込みアクセス権を持たないユーザーが変更を加えることができます。フォークワークフローは、パブリックプロジェクトへのコントリビューションのために、オープンソースコミュニティにとって特に重要です。ただし、責任の明確な分離とより厳密なアクセス制御を好む一部の企業でも同様に重要です。プロジェクトへのアクセスは、指定された開発者のリストに制限されます。
フォークによって以下が可能になります：
- アップストリームプロジェクトを変更できる人物のより厳密な管理。
- 責任の分離：親プロジェクトは本番システムに接続する CI 設定を使用する場合があります。
- フォークのコンテキストで、より制限的な環境で CI パイプラインを実行します。
- すべてのフォークを未検証として扱い、シークレットやプロジェクトに紐づく情報の漏洩リスクを軽減します。
フォークモデルは、以下の理由から Cells アーキテクチャで問題になります：
- フォークは既存のリポジトリのクローンです。フォークは異なる Organization、Cell、Gitaly シャードをまたいで作成される可能性があります。
- ユーザーはマージリクエストを作成して、アップストリームプロジェクトにコントリビューションできます。このアップストリームプロジェクトは異なる Organization と Cell にある場合があります。
- マージリクエストの CI パイプラインはソースプロジェクトのコンテキストで実行されますが、ターゲットプロジェクトのコンテキストで表示されます。
2. データ調査
データ調査 から、既存のフォークについて以下の情報が得られました：
- GitLab.com に現在約 180 万のフォークが存在します。
- フォークの大部分は個人名前空間に存在します（82%）。
- 同じトップレベルグループや Organization 内でのフォーク使用が最小限であることを期待していました。フォークは、プロジェクトへのアクセス権を持たないユーザーにのみ必要です。企業内では、異なるチームメンバー間で何らかの理由で異なるパーミッションがある場合を除き、チームがフォークワークフローをあまり使用しないと予想されます。データによると、フォーク関係の 9% のみが一致するアルティメット親名前空間識別子（トップレベルグループと個人名前空間）を持っています。残りの 91% のフォーク関係は異なるトップレベル名前空間をまたいでフォークされています。トップレベルグループを識別可能な会社に対応させようとした結果：
- フォークされたプロジェクトの 3% は同じ Organization のアップストリームプロジェクトからフォークされています。
- フォークされたプロジェクトの 83% は、アップストリームまたはダウンストリームのプロジェクトのどちらにも識別可能な Organization がありません。
- 残りの 14% は、異なる企業のソースプロジェクトからフォークされています。
- 過去 12 ヶ月間に活動のあるトップレベルグループ（95k）の 9% がフォーク関係を持つプロジェクトを保有しており、過去 12 ヶ月間に活動のないトップレベルグループ（91k）の 5% と比較されます。これらのトップレベルグループは Cells の影響を受けると予想されます。
3. 提案
3.1. フォークは現在の Organization の専用コントリビューションスペースに作成される
Organization をまたいでプロジェクトを作成する代わりに、フォークは Organization に紐づいたコントリビューションスペースに作成されます。コントリビューションスペースは個人名前空間に似ていますが、デフォルト Organization に存在するのではなく、誰かがコントリビューションしようとしている Organization 内に存在します。例：
- Organization を閲覧できるユーザー（パブリック Organization の全ユーザー）は、その Organization にコントリビューションスペースを作成できます。これは、その Organization のプロジェクトのフォークを作成できる専用の名前空間です。例えば、
Produce Inc.の場合はgitlab.com/organization/produce-inc/@ayufanのようになります。 - コントリビューションスペースの作成には Organization のメンバーシップは不要です。これにより、コントリビューターがグループやプロジェクトに招待されることなくフォークしてマージリクエストを作成できるオープンソースワークフローが妨げられないためです。公開設定を厳密に尊重するため、プライベート Organization にまず招待されることなく、ユーザーはプライベート Organization にフォークを作成できません。
- プロジェクトのフォークを作成する際、ユーザーには Organization の一部であるグループ内にフォークを作成するオプションのみが表示されます。また、コントリビューションスペースを作成してそこにフォークを配置するオプションも提供されます。現在、フォーク作成時には「グループを作成」オプションもあります。この機能も新しいフォークを保存するために Organization 内に新しいグループを作成することに制限されます。
- コントリビューションしないでフォークしたいユーザーをサポートするため、書き込み権限を持つ任意の名前空間に リンクなしフォーク を作成するオプションを検討する可能性があります。
- ユーザーはコントリビューションする Organization の数だけコントリビューションスペースを持ちます。
- ユーザーはコントリビューションスペース内に追加の個人プロジェクトを作成できません。個人プロジェクトは引き続き個人名前空間に作成できます。
- Organization はコントリビューションスペースの使用を禁止または無効化できます。これにより、Organization 内のグループに属さないユーザーによるフォークが無効化されます。
- 現在のすべてのフォークは、Organization 内のユーザーのコントリビューションスペースに移行されます。フォークにアップストリームプロジェクト外のデータへのリンクも含まれている場合、データの損失が生じる可能性があるため、個人プロジェクトもアーカイブされた状態で保持し、フォーク関係を削除します。
- すべてのフォークは Organization の一部です。
- フォークはフェデレーション機能ではありません。
- コントリビューションスペースとフォークされたプロジェクトは、親プロジェクトと設定を共有しません。
- Organization が削除された場合、フォークを含むプロジェクトはデフォルト Organization に移動されるか、それらを収容する新しい Organization が作成されます。これは基本的に旧 Organization のゴーストとなる Organization です。
- コントリビューションスペースのデータは、課金の観点からカスタマーの使用量にはカウントされません。
- 現在は Organization スコープのランナーはありませんが、実装された場合、コントリビューションスペースのプロジェクトでどのように使用できるか、または使用できないかについて特別な設定が必要になる可能性があります。
3.2. クラスター内フォーク
この提案では、フォークをクラスター内フォークとして実装し、クラスターの信頼された Cell 間で API を介して通信します：
- フォークは常にユーザーが選択したグループのコンテキストで作成されます。
- フォークは Organization から分離されています。
- Organization またはグループのオーナーは、Organization をまたいだフォーク、またはフォーク全般を無効化できます。
- マージリクエストはターゲットプロジェクトのコンテキストで作成され、別の Cell の外部プロジェクトを参照します。
- ターゲットプロジェクトには、ターゲットプロジェクトのコンテキストでの情報表示に使用されるマージ参照が転送されます。
- CI パイプラインは今日と同様にソースプロジェクトのコンテキストでフェッチされ、結果はターゲットプロジェクトのマージリクエストにフェッチされます。
- ターゲットプロジェクトを保持する Cell は、GraphQL を使用してソースプロジェクトの状態をフェッチし、マージリクエストの情報コンテキストに含めます。
メリット：
- 既存のすべてのフォークは、クラスター内フォークとして扱われるため、そのまま機能し続けます。
デメリット：
- Organization の目的は、Organization 間の強固な分離を提供することです。フォークをまたいで許可することで、セキュリティ境界が破られます。
- ただし、これは今日のユーザーがリポジトリをローカルコンピューターにクローンして任意のリポジトリにプッシュできる能力と変わりません。
- ソースプロジェクトのアクセス制御がターゲットプロジェクトよりも低い場合があります。現在、コントリビューションを行うには、フォークとアップストリームプロジェクトのアクセスレベルが同じである必要があります。
3.3. フォークは現在のプロジェクトの配下に内部プロジェクトとして作成される
Organization をまたいでプロジェクトを作成する代わりに、フォークは既存のプロジェクトの添付ファイルとして扱われます。プロジェクトをフォークする各ユーザーは、固有のプロジェクトを受け取ります。例：
- プロジェクト
gitlab.com/gitlab-org/gitlabの場合、フォークはgitlab.com/gitlab-org/gitlab/@kamil-gitlabに作成されます。 - フォークは現在の Organization のコンテキストで作成され、Organization の境界をまたがず、Organization によって管理されます。
- ユーザー（またはフォークにユーザーが提供した任意の名前）に紐づきます。
- フォークはフェデレーション機能ではありません。
デメリット：
- 既存のすべてのフォークを処理および移行する方法に対応していません。
- 現在のグループ/プロジェクト設定を共有する可能性があり、一部のセキュリティ境界を破ることになる場合があります。
3.4. フォークは現在の Organization の個人名前空間に作成される
すべてのユーザーは、各パブリック Organization に個人名前空間を持つ可能性があります。最初に Organization を訪問すると、ユーザーはその Organization にスコープされた個人名前空間を受け取ります。ユーザーは、アップストリームリポジトリが個人名前空間と同じ Organization にある場合に、個人名前空間にフォークできます。Organization を削除すると、その Organization 内の個人名前空間も削除されます。
メリット：
- 既存のほとんどのコードパスを再利用します。
- 既存のほとんどの製品設計ルールを再利用します。
- Organization の境界が自然に分離されます。
- 複数の個人名前空間により、ユーザーは個人プロジェクトを Organization ごとに分けて管理できます。
- ほとんどのユーザーは 1 つの Organization で作業すると予想されるため、大多数は個人プロジェクトをどの Organization に保存したか覚えておく必要がありません。
デメリット：
- 冗長な個人名前空間が作成されます。これは将来のイテレーションで改善される予定です。
- 多数の Organization で作業している場合、複数の個人名前空間のナビゲーションが困難になる可能性があります。これはエッジケースであると予想されます。
- 個人名前空間のライフサイクルは Organization に依存します。これは既に、プライベートに所有されるユーザーアカウント（Enterprise Users など）や、パブリックでないセルフマネージドインストールでも同様です。
- Organization の個人名前空間には新しい URL パスが必要です。
- レガシー個人名前空間パスの適応が必要です。
URL パスの変更は 議論中 です。
4. 評価
多くの難しい問題がすでに解決されているため、3.4. フォークは現在の Organization の個人名前空間に作成される に従います。URL パスの再構築や複数の個人名前空間の処理などのこのソリューションの短所は管理可能であり、他の代替提案によって生じる問題よりも重要ではありません。
5. 例
例として、gitlab-org/gitlab を別の Organization に移動した場合のこの提案の影響を示します。gitlab-org/gitlab には 8K 以上のフォーク があります。
この方向性はこれらのフォークの標準 URL に影響しますか？
はい、フォークの標準 URL は変更されます。具体的なパスの変更は 議論中 です。レガシー個人名前空間にフォークを持ち、マージリクエストのコントリビューションを継続したいユーザーは、フォークをソースプロジェクト Organization の個人名前空間に移行する必要があります。例えば、https://gitlab.com/DylanGriffith/gitlab にある個人名前空間のフォークは、https://gitlab.com/-/organizations/gitlab-inc/@DylanGriffith/gitlab に移行する必要があります。これを自動化する方法を提供するかもしれませんが、手動での手順は以下の通りです：
- コントリビューションスペースのフォークを作成してください
- 元のフォークからローカルブランチを新しいフォークにプッシュしてください
- まだオープンしてマージしたいマージリクエストを再作成してください
リポジトリ自体の Git URL に影響しますか？
はい。具体的なパスの変更は 議論中 です。
フォークの移動を承認するためにユーザーのアクションが必要ですか？
いいえ。フォークは Organization 内またはコントリビューションスペースに移動できます。Organization がパブリックの場合、ユーザーは個人名前空間を持ちます。
GitLab.com でホストされているパブリックプロジェクトの既存のフォークを壊さないという約束ができますか？
既存のフォークプロジェクトは削除されませんが、ソースプロジェクトが別の Organization に移動された際にフォーク関係が削除されます。オープンソースプロジェクトのオーナーは、プロジェクトを移動するとフォークとの接続が切断されることを事前に通知され、既存のすべてのマージリクエストを閉じる必要があります。これらのマージリクエストのコラボレーションやマージができなくなりながらも、その履歴を保持するための何らかのプロセスが必要です。
gitlab-org/gitlab の場合、このプロセスをできる限り事前に通知し、透明性を持って進める予定です。このプロジェクトを Organization に移動するという決定を下した際には、許容できるために必要な最低限の自動移行について追加のフィードバックを求めます。ただし、移動後はコントリビューターのワークフローが変わるため、いずれにしても転換点となるイベントになります。
