Artifacts は作業をリポジトリに保存します。リポジトリは、独自の履歴、refs、リモート URL、トークン、永続状態を持つ、独立した 1 つの Git サービスです。
すべてのリポジトリは、1 つの名前空間(namespace)に属します。名前空間がまだ存在しない場合、Artifacts は、その中に最初のリポジトリを作成するときに名前空間も作成します。
名前空間は関連するリポジトリをまとめ、リポジトリ名はそのグループ内の 1 つのリポジトリを識別します。
リポジトリには 3 つの識別子があります。
- 名前空間名
- リポジトリ名
- API が返すリポジトリ ID
名前空間とリポジトリ名は、Workers バインディング、REST API、Git リモートで使う安定したアドレスになります。リポジトリ ID は、API レスポンスやログで不透明な識別子が必要なときに使えます。
各リポジトリは、ほかのリポジトリから分離されています。トークン、ライフサイクル、refs、変更は、そのリポジトリにのみ適用されます。
Artifacts は、同じリポジトリを 3 つのインターフェースで公開します。
| インターフェース | 用途 | 戻り値 |
|---|---|---|
| Workers バインディング | Worker から作成、一覧、インポート、検査、fork、削除、トークン発行を行う | リポジトリのメタデータ、リポジトリハンドル、リポジトリスコープのトークン結果 |
| REST API | 外部システムから作成、一覧、インポート、検査、fork、削除、トークン発行を行う | リポジトリのメタデータとトークン結果を含む Cloudflare API レスポンス |
| Git プロトコル | リポジトリ内容の clone、fetch、pull、push | HTTPS 上の標準的な Git の動作 |
これらのインターフェースは、同じリポジトリを指します。
たとえば、Workers バインディング または REST API でリポジトリを作成し、返された remote URL を標準の Git クライアントに渡せます。インターフェースごとに別のリポジトリを作成する必要はありません。
Workers バインディングと REST API はコントロールプレーンのインターフェースです。リポジトリとトークンの管理に使います。
Git プロトコルはデータプレーンのインターフェースです。通常の Git ワークフローでコミット、ツリー、refs を読み書きします。
この分担から、次のよくある流れになります。
- Workers バインディングまたは REST API でリポジトリを作成します。
- リポジトリの
remoteURL を読み取ります。 - リポジトリスコープのトークンを発行します。
remoteとトークンを、git clone、git fetch、git pull、git pushで使います。
リポジトリのスコープは、命名とアクセスの 2 か所で重要です。
リポジトリ名は、アカウント全体ではなく、名前空間内で一意です。環境やテナントの構成に合わせて、短いリポジトリ名を別の名前空間で再利用できます。
たとえば、app というリポジトリは、prod 名前空間と staging 名前空間の両方に存在できます。
Artifacts のトークンはリポジトリスコープです。あるリポジトリ向けに発行したトークンは、同じ名前空間にあっても、別のリポジトリへのアクセスを許可しません。
clone、fetch、pull には read トークンを使います。クライアントが変更を push する必要がある場合にだけ、write トークンを使います。
Artifacts は、各リポジトリを 1 つの作業単位として扱うときに最も効果的です。
履歴、クリーンアップ、アクセス制御を分けたい場合は、エージェント、セッション、ユーザータスク、ベースライン、fork 先ごとに 1 リポジトリを使います。環境、テナント、シャードでそれらのリポジトリをまとめるには、名前空間を使います。
詳細は、名前空間、Artifacts の仕組み、Artifacts のベストプラクティス を参照してください。