You can set up a prebuild configuration for the combination of a specific branch of your repository with a specific dev container configuration file.
Any branches created from a prebuild-enabled parent branch will typically also get prebuilds for the same dev container configuration. This is because the prebuild for child branches that use the same dev container configuration as the parent branch are, for the most part, identical, so developers can benefit from faster codespace creation times on those branches also. For more information, see "Introduction to dev containers."
Typically, when you configure prebuilds for a branch, prebuilds will be available for multiple machine types. However, if your repository is greater than 32 GB, prebuilds won't be available for 2-core and 4-core machine types, since the storage these provide is limited to 32 GB.
Before you can configure prebuilds for your project the following must be true:
- GitHub Codespaces must be enabled for your organization. For more information, see "Enabling GitHub Codespaces for your organization."
- GitHub Actions must be enabled for your repository. Each prebuild configuration needs to be able to trigger an associated Actions workflow. For more information, see "Managing GitHub Actions settings for a repository."
En GitHub.com, vaya a la página principal del repositorio.
Debajo del nombre del repositorio, haz clic en Configuración.
In the "Code & automation" section of the sidebar, click Codespaces.
In the "Prebuild configuration" section of the page, click Set up prebuild.
Choose the branch for which you want to set up a prebuild.
Note: Any branches created from a prebuild-enabled base branch will typically also get prebuilds for the same dev container configuration. For example, if you enable prebuilds for a dev container configuration file on the default branch of the repository, branches based on the default branch will, in most cases, also get prebuilds for the same dev container configuration.
Optionally, in the Configuration file drop-down menu that's displayed, choose the
devcontainer.jsonconfiguration file that you want to use for this prebuild. For more information, see "Introduction to dev containers."
Choose how you want to automatically trigger updates of the prebuild.
- Every push (the default setting) - With this setting, prebuild configurations will be updated on every push made to the given branch. This will ensure that codespaces generated from a prebuild always contain the latest codespace configuration, including any recently added or updated dependencies.
- On configuration change - With this setting, prebuild configurations will be updated every time associated configuration files for a given repo and branch are updated. This ensures that changes to the dev container configuration files for the repository are used when a codespace is generated from a prebuild. The Actions workflow that updates the prebuild will run less often, so this option will use fewer Actions minutes. However, this option will not guarantee that codespaces always include recently added or updated dependencies, so these may have to be added or updated manually after a codespace has been created.
- Scheduled - With this setting, you can have your prebuild configurations update on a custom schedule that's defined by you. This can reduce consumption of Actions minutes, however, with this option, codespaces may be created that do not use the latest dev container configuration changes.
Optionally, select Reduce prebuild available to only specific regions to limit access to your prebuild, then select which regions you want it to be available in. Developers can only create codespaces from a prebuild if they are located in a region you select. By default, your prebuild is available to all regions where codespaces is available and storage costs apply for each region.
- The prebuild for each region will incur individual charges. You should, therefore, only enable prebuilds for regions in which you know they'll be used. For more information, see "About GitHub Codespaces prebuilds."
- Developers can set their default region for GitHub Codespaces, which can allow you to enable prebuilds for fewer regions. For more information, see "Setting your default region for GitHub Codespaces."
Optionally, set the number of prebuild versions to be retained. You can input any number between 1 and 5. The default number of saved versions is 2, which means that only the latest template version and the previous version are saved.
Depending on your prebuild trigger settings, your prebuild could change with each push or on each dev container configuration change. Retaining older versions of prebuilds enables you to create a prebuild from an older commit with a different dev container configuration than the current prebuild. Since there is a storage cost associated with retaining prebuild versions, you can choose the number of versions to be retained based on the needs of your team. For more information on billing, see "About billing for GitHub Codespaces."
If you set the number of prebuild versions to save to 1, GitHub Codespaces will only save the latest version of the prebuild and will delete the older version each time the template is updated. This means you will not get a prebuilt codespace if you go back to an older dev container configuration.
Optionally, add users or teams to notify when the prebuild workflow run fails for this configuration. You can begin typing a username, team name, or full name, then click the name once it appears to add them to the list. The users or teams you add will receive an email when prebuild failures occur, containing a link to the workflow run logs to help with further investigation.
Si la configuración del contenedor de desarrollo para el repositorio especifica permisos para acceder a otros repositorios, se te mostrará una página de autorización. Para obtener más información sobre cómo se especifica esto en el archivo
devcontainer.json, consulta "Administración del acceso a otros repositorios del codespace".
Haz clic en para ver los detalles de los permisos solicitados.
Haz clic en Autorizar y continuar para conceder estos permisos para la creación de la precompilación. Como alternativa, puedes hacer clic en Continuar sin autorizar, pero, si lo haces, es posible que los espacios de código creados a partir de la precompilación resultante no funcionen correctamente.
Nota: También se pedirá que concedan estos permisos a los usuarios que creen codespaces que usan esta precompilación.
After you create a prebuild configuration it is listed on the GitHub Codespaces page of your repository settings. A GitHub Actions workflow is queued and then run to create prebuilds in the regions you specified, based on the branch and dev container configuration file you selected.
For information about editing and deleting prebuild configurations, see "Managing prebuilds."
To allow the prebuild process to access environment variables required to create your development environment, you can set these either as Codespaces repository secrets or as Codespaces organization secrets. For more information, see "Adding secrets for a repository" and "Adding secrets for an organization."
Secrets that you create in this way will be accessible by anyone who creates a codespace from this repository. If you do not want this, you can alternatively set the
CODESPACES_PREBUILD_TOKEN secret. The
CODESPACES_PREBUILD_TOKEN secret is only used for prebuilding and its value is not accessible in users' codespaces.
Prebuilds cannot use any user-level secrets while building your environment, because these are not available until after the codespace has been created.
You can use the
updateContentCommand commands in your
devcontainer.json to include time-consuming processes as part of the prebuild creation. For more information, see the Visual Studio Code documentation, "devcontainer.json reference."
onCreateCommand is run only once, when the prebuild is created, whereas
updateContentCommand is run at template creation and at subsequent template updates. Incremental builds should be included in
updateContentCommand since they represent the source of your project and need to be included for every prebuild update.