Skip to main content
ドキュメントへの更新が頻繁に発行されており、このページの翻訳はまだ行われている場合があります。 最新の情報については、「英語のドキュメント」を参照してください。

プレビルドの構成

変更をリポジトリにプッシュするたびに自動的に codespace をプレビルドするようにプロジェクトを構成できます。

この機能を使用できるユーザー

People with admin access to a repository can configure prebuilds for the repository.

プレビルド構成は、リポジトリの特定のブランチと特定の開発コンテナー構成ファイルの組み合わせに対して設定できます。

通常、プレビルドが有効な親ブランチから作られたブランチはすべて、同じ開発コンテナー構成のプレビルドも取得します。 これは、親ブランチと同じ開発コンテナー構成を使う子ブランチのプレビルドがほとんどの場合同一であるためであり、これにより、開発者はこれらのブランチの codespace の作成時間を短縮できるというメリットも得られます。 詳しくは、「開発コンテナーの概要」を参照してください。

通常、ブランチにプレビルドを構成すると、複数のマシンの種類でプレビルドを使用できるようになります。 しかし、リポジトリが 32 GB を超える場合、提供されるストレージは 32 GB に制限されているため、2 コアと 4 コアのマシンの種類ではプレビルドを使用できません。

前提条件

プレビルドは、GitHub Actions を使用して作成されます。 その結果、プレビルドを構成するリポジトリに対して GitHub Actions を有効にする必要があります。 詳しくは、「リポジトリの GitHub Actions の設定を管理する」を参照してください。

プレビルドの構成

  1. GitHub.com で、リポジトリのメイン ページへ移動します。 1. リポジトリ名の下にある [設定] をクリックします。 [セキュリティ] タブが表示されない場合は、 [] ドロップダウン メニューを選び、 [設定] をクリックします。

    タブを示すリポジトリ ヘッダーのスクリーンショット。 [設定] タブが濃いオレンジ色の枠線で強調表示されています。

  2. サイド バーの [コードと自動化] セクションで、 [Codespaces] をクリックします。

  3. ページの [プレビルド構成] セクションで、 [プレビルドの設定] をクリックします。

    [Codespaces] 設定ページの [プレビルド構成] セクションのスクリーンショット。[プレビルドの設定] ボタンが表示されています。

  4. プレビルドを設定するブランチを選びます。

    プレビルドの [構成] 設定のスクリーンショット。ドロップダウン メニューには選択対象のブランチが一覧表示されています。 "main" ブランチが現在選択されています。

    : 通常、プレビルドが有効なベース ブランチから作られたブランチはすべて、同じ開発コンテナー構成のプレビルドも取得します。 たとえば、リポジトリの既定のブランチで開発コンテナー構成ファイルのプレビルドを有効にすると、ほとんどの場合、既定のブランチに基づくブランチも同じ開発コンテナー構成のプレビルドを取得するようになります。

  5. 必要に応じて、表示される [構成ファイル] ドロップダウン メニューで、ご自分のプレビルドに使う devcontainer.json 構成ファイルを選びます。 詳しくは、「開発コンテナーの概要」を参照してください。

    構成ファイルのドロップダウン メニューのスクリーンショット。 4 つの構成ファイルが一覧表示されており、".devcontainer/devcontainer.json" が現在選択されています。

  6. プレビルドの更新を自動的にトリガーする方法を選びます。

    • すべてのプッシュ (既定の設定) - この設定では、特定のブランチに対して行われるすべてのプッシュで、プレビルドの構成が更新されます。 これにより、プレビルドから生成された codespace には、最近追加または更新された依存関係を含む最新の codespace 構成が常に含まれます。

    • 構成変更時 - この設定では、次のいずれかのファイルが変更されるたびにプレビルドが更新されます。

      • .devcontainer/devcontainer.json

        : プレビルドの更新は、.devcontainer のサブディレクトリ内の devcontainer.json ファイルに対する変更によってトリガーされることはありません。

      • .devcontainer/devcontainer.json ファイルの build.dockerfile プロパティで参照される Dockerfile。

      この設定により、プレビルドから codespace が生成されるときに、リポジトリの開発コンテナー構成ファイルに対する変更が確実に使用されます。 プレビルドを更新する GitHub Actions ワークフローは実行頻度が低いため、このオプションでは使用する GitHub Actions の使用時間 (分) が少なくなります。 ただし、このオプションでは、codespace に常に最近追加または更新された依存関係が含まれるという保証はないため、codespace の作成後に手動で追加または更新する必要がある場合があります。

    • スケジュール済み - この設定では、ユーザーが定義したカスタム スケジュールに基づいてプレビルドを更新できます。 これにより、GitHub Actions の使用時間 (分) を減らすことができますが、このオプションでは、最新の開発コンテナー構成の変更を使用しない codespace を作成できます。

    [プレビルド トリガー] 設定のスクリーンショット。 [スケジュール済み] オプションが選択されており、"毎日" の "午後 1 時" と "午後 3 時 30 分" に設定されています。

  7. 必要に応じて、 [特定のリージョンでのみ使用できるプレビルドを減らす] を選び、指定したリージョンにのみプレビルドを作成します。 プレビルドを使用できるようにするリージョンを選びます。

    既定では、使用可能なすべてのリージョンにプレビルドが作成され、プレビルドごとにストレージ料金が発生します。

    [リージョンの可用性] 設定のスクリーンショット。 [特定のリージョンでのみ使用できるプレビルドを減らす] が選択されており、2 つのリージョンが選択されています。

    :

    • 各リージョンのプレビルドでは、個々のストレージ料金が発生します。 そのため、使用されることがわかっているリージョンに対してのみプレビルドを有効にする必要があります。 詳しくは、「GitHub Codespaces の請求について」を参照してください。
    • 開発者は、GitHub Codespaces の既定のリージョンを設定できます。これにより、より少ないリージョンでプレビルドを有効にすることができます。 詳しくは、「GitHub Codespaces の既定のリージョンを設定する」を参照してください。
  8. 必要に応じて、 [テンプレートの履歴] で、保持するプレビルドのバージョンを設定します。 1 から 5 の任意の数を入力できます。 保存されるバージョンの既定の数は 2 です。つまり、最新のプレビルドと前のバージョンのみが保存されます。

    [テンプレートの履歴] 設定のスクリーンショット。 2 つのバージョンに設定されています。

    プレビルドのトリガー設定によっては、プッシュごと、または開発コンテナー構成の変更ごとに、プレビルドが変更される可能性があります。 以前のバージョンのプレビルドを保持すると、現在のプレビルドとは異なる開発コンテナー構成を使用して、以前のコミットからプレビルドを作成できます。 この設定を使用すると、保持されているバージョンの数を、ニーズに適したレベルに設定できます。

    保存するプレビルドのバージョンの数を 1 に設定した場合、GitHub Codespaces によりプレビルドの最新バージョンのみが保存され、テンプレートが更新されるたびに古いバージョンが削除されます。 つまり、以前の開発コンテナー構成に戻った場合、プレビルドの codespace は取得されません。

    保持されている各プレビルド バージョンには、ストレージ コストが関連付けられています。 たとえば、4 つのリージョンでプレビルドを生成し、2 つのバージョンを保持している場合、最大 8 つのプレビルドのストレージに対して課金されます。 課金について詳しくは、「GitHub Codespaces の請求について」をご覧ください。

  9. 必要に応じて、この構成でプレビルド ワークフローの実行が失敗したときに通知するユーザーまたはチームを追加します。 ユーザー名、チーム名、またはフル ネームの入力を開始し、表示されたら名前をクリックしてリストに追加できます。 追加したユーザーまたはチームは、プレビルド エラーが発生したときに電子メールを受信します。詳しい調査に役立つワークフロー実行ログへのリンクが含まれています。

    [失敗通知] 設定のスクリーンショット。 "octocat-team" という名前のチームが追加されました。

  10. 必要に応じて、ページの下部にある [詳細オプションの表示] をクリックします。

    プレビルド構成ページの下部のスクリーンショット。 [詳細オプションの表示] リンクが濃いオレンジ色の枠線で強調表示されています。

    [詳細オプション] セクションで、 [プレビルドの最適化を無効にする] を選んだ場合、最新のプレビルド ワークフローが失敗したか、現在実行中の場合は、プレビルドなしで codespace が作成されます。 詳しくは、「プレビルドに関するトラブルシューティング」を参照してください。

  11. Create をクリックしてください。

    リポジトリの開発コンテナー構成で他のリポジトリにアクセスするためのアクセス許可が指定されている場合は、認可ページが表示されます。 devcontainer.json ファイルでこれを指定する方法について詳しくは、「codespace 内の他のリポジトリへのアクセスの管理」をご覧ください。

    をクリックして、要求されたアクセス許可の詳細を表示します。

    プレビルド構成の承認ページのスクリーンショット。 この要求では、3 つのアクセス許可が指定されています。

    [認可して続行する] をクリックし、プレビルドを作成するためにこれらのアクセス許可を付与します。 または、 [認可せずに続行する] をクリックすることもできますが、その場合は、結果のプレビルドから作られる codespace が正しく機能しない可能性があります。

    : このプレビルドを使って codespace を作るユーザーも、これらのアクセス許可を付与するように求められます。

プレビルド構成を作ると、リポジトリ設定の GitHub Codespaces ページに一覧表示されます。 GitHub Actions ワークフローがキューに登録され、指定したリージョンで、選んだブランチと開発コンテナー構成ファイルに基づいて、プレビルドを作るために実行されます。

プレビルド構成の一覧のスクリーンショット。 "現在実行中" という 1 つのプレビルドが表示されています。 その右側に [出力の表示] ボタンがあります。

プレビルド構成の編集と削除について詳しくは、「事前ビルドの管理」を参照してください。

環境変数の設定

開発環境を作成するために必要な環境変数にプレビルド プロセスでアクセスできるようにするには、これらを Codespaces リポジトリ シークレットとして、または Codespaces Organization シークレットとして設定できます。 詳細については、「リポジトリの暗号化されたシークレットと GitHub Codespaces の Organization を管理する」および「リポジトリの暗号化されたシークレットと GitHub Codespaces の Organization を管理する」を参照してください。

この方法で作ったシークレットは、このリポジトリから codespace を作るすべてのユーザーがアクセスできます。 そのようにしたくない場合は、代わりに CODESPACES_PREBUILD_TOKEN シークレットを設定できます。 CODESPACES_PREBUILD_TOKEN シークレットはプレビルドにのみ使用され、ユーザーの codespace ではその値にアクセスできません。

環境の構築中は、プレビルドでユーザー レベルのシークレットを使うことはできません。これは、codespace が作られるまで利用できないためです。

プレビルドに含める時間のかかるタスクの構成

devcontainer.jsononCreateCommand および updateContentCommand コマンドを使用して、プレビルド作成の一部として時間のかかるプロセスを含めることができます。 詳細については、Visual Studio Code のドキュメントの「devcontainer.json リファレンス」を参照してください。

onCreateCommand はプレビルドが作成されるときに 1 回だけ実行されますが、updateContentCommand はテンプレートの作成時とそれ以降の更新時に実行されます。 インクリメンタル ビルドは updateContentCommand に含める必要があります。これらはプロジェクトのソースを表し、プレビルドの更新ごとに含める必要があるためです。

参考資料