This page contains information related to upcoming products, features, and functionality.
It is important to note that the information presented is for informational purposes only.
Please do not rely on this information for purchasing or planning purposes.
As with all projects, the items mentioned on this page are subject to change or delay.
The development, release, and timing of any products, features, or functionality remain at the
sole discretion of GitLab Inc.
| Status | Authors | Coach | DRIs | Owning Stage | Created |
|---|---|---|---|---|---|
| proposed | - |
このドキュメントは作業中のものであり、セルズの設計のごく初期の状態を表しています。重要な点は文書化されていませんが、将来的には追加される予定です。これはCellsの可能性のあるアーキテクチャの一つであり、どのアプローチを実装するか決める前に、代替案と比較検討するつもりです。この文書化は、このアプローチを選ばなかった理由を文書化できるよう、これを実装しないと決めた場合でも残しておきます。
Cells：貢献者：フォーク
フォークワークフローにより、ユーザーは既存のプロジェクトソースを自分の名前空間（個人またはグループ）にコピーすることができます。
1.定義
Forkingワークフローは、様々な使用パターンを持つ一般的なワークフローです：
- ユーザーはアップストリームプロジェクトに貢献することができます。
- リポジトリを個人ネームスペースに永続化します。
- ユーザーはコピーして変更を加え、変更されたプロジェクトとしてリリースすることができます。
フォークは、親プロジェクトへの書き込み権限を持たないユーザーが変更を加えることを可能にします。フォークワークフローは、公開プロジェクトに貢献するオープンソースコミュニティにとって特に重要です。しかし、責任の分担や、より厳密なアクセス制御を好む企業においても、同様に重要です。プロジェクトへのアクセスは、指定された開発者リストに制限されます。
フォークが可能にします：
- 誰がアップストリームプロジェクトを変更できるかをより厳しく管理。
- 責任の分担：親プロジェクトは、本番システムに接続する CI 設定を使うかもしれません。
- フォークのコンテキストでCIパイプラインをより制限された環境で実行するため。
- すべてのフォークをunvettedとみなすことで、シークレットやプロジェクトに関連する情報を漏らすリスクを減らします。
Cellsアーキテクチャでは、以下の理由でフォークモデルが問題になります：
- フォークは既存のリポジトリのクローンです。フォークは、異なるOrganization、Cells、Gitalyシャード間で作成される可能性があります。
- ユーザーはマージリクエストを作成し、アップストリームプロジェクトに貢献することができます。このアップストリームプロジェクトは、異なる組織やセルにあるかもしれません。
- マージリクエストのCIパイプラインは、ソースプロジェクトのコンテキストで実行されますが、ターゲットプロジェクトのコンテキストで表示されます。
2.データフロー
3.提案
3.1.クラスター内フォーク
本提案では、クラスターの信頼されたすべてのCell間でAPIを介して通信を行うクラスタ内フォークを実装します：
- フォークは常にユーザーが選択したグループのコンテキストで作成されます。
- フォークは組織から分離されます。
- 組織またはグループのオーナーは、組織間でのフォーク、または一般的なフォークを無効にすることができます。
- マージリクエストはターゲットプロジェクトのコンテキストで作成され、別のセルの外部プロジェクトを参照します。
- マージ参照は、ターゲットプロジェクトのコンテキストで情報を表示するために使用されます。
- CI パイプラインはソースプロジェクトのコンテキストでフェッチされ、その結果はターゲットプロジェクトのマージリクエストにフェッチされます。
- ターゲットプロジェクトを保持するセルは、内部で GraphQL を使用してソースプロジェクトのステータスをフェッチし、マージリクエストの情報のコンテキストに含めます。
利点
- 既存のすべてのフォークはクラスタ内フォークとして扱われるため、そのまま機能し続けます。
デメリット
- Organizationsの目的は、Organizations間の強固な分離を提供することです。組織間のフォークを許可すると、セキュリティの境界が破られます。
- しかし、これは今日のユーザーがリポジトリをローカルコンピュータにクローンし、任意のリポジトリにプッシュする能力と変わりません。
- ソースプロジェクトのアクセスコントロールは、ターゲットプロジェクトよりも低くすることができます。現在では、貢献し返すためには、フォークとアップストリームでアクセスレベルを同じにする必要があります。
3.2.フォークは、現在の組織の個人ネームスペースに作成されます。
組織にまたがってプロジェクトを作成する代わりに、フォークは組織に結びついたユーザーの Personal Namespace に作成されます。例
- 組織の一員である各ユーザーは、自分の Personal Namespace を受け取ります。たとえば、
GitLab Inc.の場合は、gitlab.com/organization/gitlab-inc/@ayufanとなります。 - ユーザーは組織の個人ネームスペースにフォークする必要があります。
- ユーザーは、所属する組織の数だけ個人ネームスペースを持ちます。
- Personal Namespace は、現在提供されている Personal Namespace と同様の動作をします。
- ユーザーは Personal Namespace 内でプロジェクトを管理および作成できます。
- 組織は、個人ネームスペースの使用を防止または無効にしたり、フォークを禁止したりできます。
- 現在のフォークはすべて、組織内のユーザーの個人ネームスペースにマイグレーションされます。
- すべてのフォークは組織の一部です。
- フォークは連携機能ではありません。
- Personal Namespaceとフォークされたプロジェクトは、親プロジェクトと設定を共有しません。
3.3.フォークは現在のプロジェクトの内部プロジェクトとして作成されます。
組織全体でプロジェクトを作成する代わりに、フォークは既存のプロジェクトにアタッチされます。プロジェクトをフォークしたユーザーは、それぞれ固有のプロジェクトを受け取ります。例
- プロジェクトの場合：
gitlab.com/gitlab-org/gitlabの場合、フォークはgitlab.com/gitlab-org/gitlab/@kamil-gitlabに作成されます。 - フォークは現在の組織のコンテキストで作成され、組織の境界を越えず、組織によって管理されます。
- ユーザー（またはその他のユーザーが提供するフォーク名）に紐付けられます。
- フォークは連携機能ではありません。
デメリット
- すべての既存のフォークをどのように扱い、マイグレーションするかについては回答していません。
- 現在のグループ/プロジェクト設定を共有する可能性があり、セキュリティの境界を破る可能性があります。