概要
プレビルドでは、リポジトリ、ブランチ、devcontainer.json 構成ファイルの特定の組み合わせに対して、codespace の主要コンポーネントが組み立てられます。 これにより、新しい codespace をすばやく作成できます。 特に複雑なリポジトリや大規模なリポジトリの場合は、プレビルドを使うことで新しい codespace をより迅速に作成できます。
リポジトリの codespace の作成に現在 2 分以上かかる場合、プレビルドを使用すると改善することがあります。 これは、プレビルドを使用する場合、プロジェクト用の codespace を作成する前に、ソース コード、エディター拡張機能、プロジェクトの依存関係、コマンド、構成が既にダウンロード、インストール、適用されているためです。
既定では、変更をリポジトリにプッシュするたびに、 GitHub Codespaces は GitHub Actions を使用してビルドを自動的に更新します。
リポジトリの特定のブランチ、特定の開発コンテナー構成ファイル、およびリージョンに対してプレビルドを使用できる場合は、コードスペースを作成するときに、コンピューターの種類のオプションの一覧に " Prebuild ready" ラベルが表示されます。 まだビルド前のビルドが作成されている場合は、" Prebuild in progress" ラベルが表示されます。 詳しくは、「リポジトリの codespace を作成する」をご覧ください。
![使用可能なマシンの種類の一覧 (2、4、8、16、32 コア) のスクリーンショット。すべてに [プレビルド対応] というラベルが付いています。](/assets/cb-49456/images/help/codespaces/choose-custom-machine-type.png)
[Your codespaces](コードスペース) ページでテンプレートからコードスペースを作成すると、 GitHub は自動的に事前ビルドを使用して作成時間を短縮できます。 テンプレートについて詳しくは、「テンプレートから codespace を作成する」を参照してください。
メモ
作成された各事前ビルドでは、課金対象の料金が発生するか、個人の GitHub アカウントが所有するリポジトリの場合、毎月含まれるストレージの一部を使用するストレージ領域が消費されます。 詳しくは、「GitHub Codespaces の課金」をご覧ください。
プレビルドのプロセス
プレビルドを作成するには、プレビルドの構成を設定します。 構成を保存すると、 GitHub Actions ワークフローが実行され、必要な各プレビルド (ビルドごとに 1 つのワークフロー) が作成されます。 ワークフローは、構成のプレビルドを更新する必要がある場合にも実行されます。 これは、スケジュールされた間隔、プレビルドが有効なリポジトリへのプッシュ時、または開発コンテナーの構成を変更するときに発生する可能性があります。 詳しくは、「プレビルドの構成」をご覧ください。
ビルド前の構成ワークフローを実行すると、GitHubは一時的なコードスペースを作成し、devcontainer.json ファイル内の任意のonCreateCommandおよびupdateContentCommandコマンドまでのセットアップ操作を実行します。 プレビルドの作成時に postCreateCommand コマンドは実行されません。 これらのコマンドの詳細については、VS Codeドキュメントのdevcontainer.jsonリファレンスを参照してください。 生成されたコンテナーのスナップショットが取得され、格納されます。
他の GitHub Actions ワークフローと同様に、ビルド前の構成ワークフローを実行すると、アカウントに含まれる GitHub Actions 分の一部が消費されるか、アカウントに含まれている場合は料金が GitHub Actions 分発生します。 codespace プレビルドのストレージは、アクティブな codespace または停止した codespace のストレージと同じ方法で課金されます。 詳しくは、「GitHub Codespaces の課金」をご覧ください。
ビルド前からコードスペースを作成すると、 GitHub ストレージから既存のコンテナー スナップショットがダウンロードされ、新しい仮想マシンにデプロイされ、開発コンテナー構成で指定された残りのコマンドが完了します。 リポジトリの複製など、多くの操作が既に実行されているため、プレビルドから codespace を作成する方が、プレビルドなしで作成するよりも大幅に速くなる可能性があります。 これは、リポジトリが大きい場合や onCreateCommand コマンドの実行に時間がかかる場合に当てはまります。
プレビルドが有効なブランチへの変更をプッシュする際について
既定では、ビルド前の構成を持つブランチにプッシュされるたびに、 GitHubマネージド GitHub Actions ワークフローが実行され、プレビルドが更新されます。 関連するリポジトリの開発コンテナー構成に影響を与える変更が行われたのでない限り、プレビルド ワークフローには、特定のプレビルド構成に対して一度に 1 つのワークフロー実行というコンカレンシー制限があります。 詳しくは、「開発コンテナーの概要」をご覧ください。 実行が既に進行中の場合は、現在の実行が完了した後、最後にキューに登録されたワークフロー実行が次に実行されます。
プッシュのたびにプレビルドが更新されるように設定すると、リポジトリへのプッシュが非常に多い場合、プレビルドは少なくとも、プレビルド ワークフローの実行に必要なだけ更新されます。 つまり、ワークフローの実行が完了するまでに通常 1 時間かかるとすると、実行が成功する場合は約 1 時間ごと、ブランチの開発コンテナー構成を変更するプッシュがあった場合はさらに頻繁に、リポジトリに対してプレビルドが作成されます。
たとえば、プレビルド構成が施されたブランチに対し、プッシュを5回続けて行うとします。 この状況では、次のようになります。
-
1 番目のプッシュに対するワークフローの実行が開始され、プレビルドが更新されます。
-
残りの 4 つのプッシュが開発コンテナーの構成に影響しない場合、これらに対するワークフロー実行は "保留中" 状態でキューに入れられます。
残りの 4 つのプッシュのいずれかが開発コンテナーの構成を変更する場合は、サービスはそれをスキップせず、プレビルド作成ワークフローを直ちに実行して、成功した場合はそれに応じてプレビルドを更新します。
-
最初の実行が完了すると、プッシュ 2、3、4 に対するワークフローの実行は取り消されて、最後にキューに入れられたワークフロー (プッシュ 5 に対する) が実行され、プレビルドが更新されます。