プレビルド構成は、リポジトリの特定のブランチと特定の開発コンテナー構成ファイルの組み合わせに対して設定できます。
通常、プレビルドが有効な親ブランチから作られたブランチはすべて、同じ開発コンテナー構成のプレビルドも取得します。 これは、親ブランチと同じ開発コンテナー構成を使う子ブランチのプレビルドがほとんどの場合同一であるためであり、これにより、開発者はこれらのブランチの codespace の作成時間を短縮できるというメリットも得られます。 「開発コンテナーの概要」を参照してください。
通常、ブランチにプレビルドを構成すると、複数のマシンの種類でプレビルドを使用できるようになります。 しかし、リポジトリが 32 GB を超える場合、提供されるストレージは 32 GB に制限されているため、2 コアと 4 コアのマシンの種類ではプレビルドを使用できません。
前提条件
プレビルドは、GitHub Actions を使用して作成されます。 その結果、プレビルドを構成するリポジトリに対して GitHub Actions を有効にする必要があります。 「リポジトリの GitHub Actions の設定を管理する」を参照してください。
個人アカウントが所有しているリポジトリにプレビルドを設定できます。 プレビルドによってストレージ領域が消費されます。この場合、課金対象の料金が発生するか、個人用アカウントで所有しているリポジトリでは、毎月含まれているストレージの一部が使用されます。
注: フォークされたリポジトリの事前ビルドを作成した場合、それらの事前ビルドのストレージ コストは、使用可能な間は、毎月含まれるストレージから減算されます。 含まれているすべてのストレージを使用し、請求を設定している場合は、パーソナル アカウントに請求されます。 これは、フォーク用に作成した Codespaces が、親リポジトリを所有する組織によって支払われる場合でも当てはまります。 「GitHub Codespaces の請求について」を参照してください。
Organization が所有しているリポジトリでは、その Organization が GitHub Team プランか GitHub Enterprise プランを利用している場合にプレビルドを設定できます。 また、支払い方法を追加し、Organization アカウントやその親 Enterprise に対して GitHub Codespaces の使用制限を設定しておく必要があります。 「GitHub Codespaces の使用制限の管理」および「GitHub のプラン」を参照してください。
プレビルドの構成
-
GitHub で、リポジトリのメイン ページに移動します。
-
リポジトリ名の下にある [設定] をクリックします。 [設定] タブが表示されない場合は、 [] ドロップダウン メニューを選び、 [設定] をクリックします。
-
サイド バーの [コードと自動化] セクションで、 [Codespaces] をクリックします。
-
ページの [プレビルド構成] セクションで、 [プレビルドの設定] をクリックします。
-
プレビルドを設定するブランチを選びます。
注: 通常、プレビルドが有効なベース ブランチから作られたブランチはすべて、同じ開発コンテナー構成のプレビルドも取得します。 たとえば、リポジトリの既定のブランチで開発コンテナー構成ファイルのプレビルドを有効にすると、ほとんどの場合、既定のブランチに基づくブランチも同じ開発コンテナー構成のプレビルドを取得するようになります。
-
必要に応じて、表示される [構成ファイル] ドロップダウン メニューで、ご自分のプレビルドに使う
devcontainer.json
構成ファイルを選びます。 「開発コンテナーの概要」を参照してください。 -
プレビルドの更新を自動的にトリガーする方法を選びます。
-
すべてのプッシュ (既定の設定) - この設定では、特定のブランチに対して行われるすべてのプッシュで、プレビルドの構成が更新されます。 これにより、プレビルドから生成された codespace には、最近追加または更新された依存関係を含む最新の codespace 構成が常に含まれます。
-
構成変更時 - この設定では、次のいずれかのファイルが変更されるたびにプレビルドが更新されます。
-
.devcontainer/devcontainer.json
注: プレビルドの更新は、
.devcontainer
のサブディレクトリ内のdevcontainer.json
ファイルに対する変更によってトリガーされることはありません。 -
.devcontainer/devcontainer.json
ファイルのbuild.dockerfile
プロパティで参照される Dockerfile。
この設定により、プレビルドから codespace が生成されるときに、リポジトリの開発コンテナー構成ファイルに対する変更が確実に使用されます。 プレビルドを更新する GitHub Actions ワークフローは実行頻度が低いため、このオプションでは使用する GitHub Actions の使用時間 (分) が少なくなります。 ただし、このオプションでは、codespace に常に最近追加または更新された依存関係が含まれるという保証はないため、codespace の作成後に手動で追加または更新する必要がある場合があります。
-
-
スケジュール済み - この設定では、ユーザーが定義したカスタム スケジュールに基づいてプレビルドを更新できます。 これにより、GitHub Actions の使用時間 (分) を減らすことができますが、このオプションでは、最新の開発コンテナー構成の変更を使用しない codespace を作成できます。
-
-
必要に応じて、 [特定のリージョンでのみ使用できるプレビルドを減らす] を選び、指定したリージョンにのみプレビルドを作成します。 プレビルドを使用できるようにするリージョンを選びます。
既定では、使用可能なすべてのリージョンにプレビルドが作成され、プレビルドごとにストレージ料金が発生します。
注:
- 各リージョンのプレビルドでは、個々のストレージ料金が発生します。 そのため、使用されることがわかっているリージョンに対してのみプレビルドを有効にする必要があります。 「GitHub Codespaces の請求について」を参照してください。
- 開発者は、GitHub Codespaces の既定のリージョンを設定できます。これにより、より少ないリージョンでプレビルドを有効にすることができます。 「GitHub Codespaces の既定のリージョンを設定する」を参照してください。
-
必要に応じて、 [テンプレートの履歴] で、保持するプレビルドのバージョンを設定します。 1 から 5 の任意の数を入力できます。 保存されるバージョンの既定の数は 2 です。つまり、最新のプレビルドと前のバージョンのみが保存されます。
プレビルドのトリガー設定によっては、プッシュごと、または開発コンテナー構成の変更ごとに、プレビルドが変更される可能性があります。 以前のバージョンのプレビルドを保持すると、現在のプレビルドとは異なる開発コンテナー構成を使用して、以前のコミットからプレビルドを作成できます。 この設定を使用すると、保持されているバージョンの数を、ニーズに適したレベルに設定できます。
保存するプレビルドのバージョンの数を 1 に設定した場合、GitHub Codespaces によりプレビルドの最新バージョンのみが保存され、テンプレートが更新されるたびに古いバージョンが削除されます。 つまり、以前の開発コンテナー構成に戻った場合、プレビルドの codespace は取得されません。
保持されている各プレビルド バージョンには、ストレージ コストが関連付けられています。 たとえば、4 つのリージョンでプレビルドを生成し、2 つのバージョンを保持している場合、最大 8 つのプレビルドのストレージに対して課金されます。 「GitHub Codespaces の請求について」を参照してください。
-
必要に応じて、この構成でプレビルド ワークフローの実行が失敗したときに通知するユーザーまたはチームを追加します。 ユーザー名、チーム名、またはフル ネームの入力を開始し、表示されたら名前をクリックしてリストに追加できます。 追加したユーザーまたはチームは、プレビルド エラーが発生したときに電子メールを受信します。詳しい調査に役立つワークフロー実行ログへのリンクが含まれています。
注: ユーザーは、個人設定でアクション ワークフローの失敗通知を有効にしている場合のみ、プレビルドの失敗通知を受け取ります。 「通知を設定する」を参照してください。
-
必要に応じて、ページの下部にある [詳細オプションの表示] をクリックします。
[詳細オプション] セクションで、 [プレビルドの最適化を無効にする] を選んだ場合、最新のプレビルド ワークフローが失敗したか、現在実行中の場合は、プレビルドなしで codespace が作成されます。 「プレビルドに関するトラブルシューティング」を参照してください。
-
Create をクリックしてください。
リポジトリの開発コンテナー構成で他のリポジトリにアクセスするためのアクセス許可が指定されている場合は、認可ページが表示されます。
devcontainer.json
ファイルでこれを指定する方法について詳しくは、「codespace 内の他のリポジトリへのアクセスの管理」をご覧ください。をクリックして、要求されたアクセス許可の詳細を表示します。
[認可して続行する] をクリックし、プレビルドを作成するためにこれらのアクセス許可を付与します。 または、 [認可せずに続行する] をクリックすることもできますが、その場合は、結果のプレビルドから作られる codespace が正しく機能しない可能性があります。
注: このプレビルドを使って codespace を作成するユーザーも、これらのアクセス許可を付与するように求められます。
プレビルド構成を作ると、リポジトリ設定の GitHub Codespaces ページに一覧表示されます。 GitHub Actions ワークフローがキューに登録され、指定したリージョンで、選んだブランチと開発コンテナー構成ファイルに基づいて、プレビルドを作るために実行されます。
プレビルド構成の編集と削除について詳しくは、「事前ビルドの管理」を参照してください。
環境変数の設定
開発環境を作成するために必要な環境変数にプレビルド プロセスでアクセスできるようにするには、これらを Codespaces リポジトリ シークレットとして、または Codespaces Organization シークレットとして設定できます。 この方法で作ったシークレットは、このリポジトリから codespace を作るすべてのユーザーがアクセスできます。 「リポジトリまたは Organization の開発環境シークレットの管理」を参照してください。
環境の構築中は、プレビルドでユーザー レベルのシークレットを使うことはできません。これは、codespace が作られるまで利用できないためです。
プレビルドに含める時間のかかるタスクの構成
devcontainer.json
で onCreateCommand
および updateContentCommand
コマンドを使用して、プレビルド作成の一部として時間のかかるプロセスを含めることができます。 Visual Studio Code のドキュメントの devcontainer.json リファレンスを参照してください。
onCreateCommand
はプレビルドが作成されるときに 1 回だけ実行されますが、updateContentCommand
はテンプレートの作成時とそれ以降の更新時に実行されます。 インクリメンタル ビルドは updateContentCommand
に含める必要があります。これらはプロジェクトのソースを表し、プレビルドの更新ごとに含める必要があるためです。