GitHub Codespaces prebuilds について

概要

プレビルドでは、リポジトリ、ブランチ、devcontainer.json 構成ファイルの特定の組み合わせに対して、codespace の主要コンポーネントが組み立てられます。 これにより、新しい codespace をすばやく作成できます。 特に複雑なリポジトリや大規模なリポジトリの場合は、プレビルドを使うことで新しい codespace をより迅速に作成できます。

リポジトリの codespace の作成に現在 2 分以上かかる場合、プレビルドを使用すると改善することがあります。 これは、プレビルドを使用する場合、プロジェクト用の codespace を作成する前に、ソース コード、エディター拡張機能、プロジェクトの依存関係、コマンド、構成が既にダウンロード、インストール、適用されているためです。

既定では、リポジトリに変更をプッシュするたびに、GitHub Codespaces は GitHub Actions を使って、プレビルドを自動的に更新します。

リポジトリの特定のブランチ、特定の開発コンテナー構成ファイル、自分のリージョンでプレビルドを使用できる場合、codespace を作成するときに、コンピューターの種類オプションの一覧に、 [Prebuild ready] というラベルが表示されます。 プレビルドがまだ作成中の場合、 [Prebuild in progress] というラベルが表示されます。 詳しくは、「AUTOTITLE」をご覧ください。

"Your codespaces" ページでテンプレートから codespace を作成するとき、GitHub では、自動的にプレビルドを使用して作成時間を短縮できます。 テンプレートについて詳しくは、「AUTOTITLE」を参照してください。

プレビルドのプロセス

プレビルドを作成するには、プレビルドの構成を設定します。 構成を保存すると、GitHub Actions ワークフローが実行され、必要な各ビルド (プレビルドごとに 1 つのワークフロー) が作成されます。 ワークフローは、構成のプレビルドを更新する必要がある場合にも実行されます。 これは、スケジュールされた間隔、プレビルドが有効なリポジトリへのプッシュ時、または開発コンテナーの構成を変更するときに発生する可能性があります。 詳しくは、「AUTOTITLE」をご覧ください。

プレビルドの構成ワークフローが実行されると、GitHub により一時的な codespace が作成され、ファイル内の設定操作が実行されます。この操作にはファイルにある任意のコマンドを含め、全ての設定操作が含まれます。 プレビルドの作成時に コマンドは実行されません。 これらのコマンドについて詳しくは、VS Code ドキュメントの「 リファレンス」を参照してください。 生成されたコンテナーのスナップショットが取得され、格納されます。

その他の GitHub Actions ワークフローと同様に、プレビルド構成ワークフローを実行すると、アカウントに含まれている GitHub Actions 分がある場合はそれを消費し、ない場合は GitHub Actions 分の使用料が請求されます。 codespace プレビルドのストレージは、アクティブな codespace または停止した codespace のストレージと同じ方法で課金されます。 詳しくは、「AUTOTITLE」をご覧ください。

プレビルドから codespace を作成すると、GitHub によりストレージから既存のコンテナー スナップショットがダウンロードされ、それを新しい仮想マシンにデプロイし、開発コンテナー構成で指定された残りのコマンドを完了します。 リポジトリの複製など、多くの操作が既に実行されているため、プレビルドから codespace を作成する方が、プレビルドなしで作成するよりも大幅に速くなる可能性があります。 これは、リポジトリが大きい場合や コマンドの実行に時間がかかる場合に当てはまります。

プレビルドが有効なブランチへの変更をプッシュする際について

既定では、プレビルドの構成があるブランチにプッシュするたびに、GitHub で管理される GitHub Actions ワークフローが実行され、プレビルドが更新されます。 関連するリポジトリの開発コンテナー構成に影響を与える変更が行われたのでない限り、プレビルド ワークフローには、特定のプレビルド構成に対して一度に 1 つのワークフロー実行というコンカレンシー制限があります。 詳しくは、「AUTOTITLE」をご覧ください。 実行が既に進行中の場合は、現在の実行が完了した後、最後にキューに登録されたワークフロー実行が次に実行されます。

プッシュのたびにプレビルドが更新されるように設定すると、リポジトリへのプッシュが非常に多い場合、プレビルドは少なくとも、プレビルド ワークフローの実行に必要なだけ更新されます。 つまり、ワークフローの実行が完了するまでに通常 1 時間かかるとすると、実行が成功する場合は約 1 時間ごと、ブランチの開発コンテナー構成を変更するプッシュがあった場合はさらに頻繁に、リポジトリに対してプレビルドが作成されます。

たとえば、プレビルド構成が施されたブランチに対し、プッシュを5回続けて行うとします。 この状況では、次のようになります。

• 1 番目のプッシュに対するワークフローの実行が開始され、プレビルドが更新されます。

• 残りの 4 つのプッシュが開発コンテナーの構成に影響しない場合、これらに対するワークフロー実行は "保留中" 状態でキューに入れられます。

  残りの 4 つのプッシュのいずれかが開発コンテナーの構成を変更する場合は、サービスはそれをスキップせず、プレビルド作成ワークフローを直ちに実行して、成功した場合はそれに応じてプレビルドを更新します。

• 最初の実行が完了すると、プッシュ 2、3、4 に対するワークフローの実行は取り消されて、最後にキューに入れられたワークフロー (プッシュ 5 に対する) が実行され、プレビルドが更新されます。