Part 1: First fourth content unordered lists from dash to asterisk (#51094)
This commit is contained in:
Grace Park
@@ -50,9 +50,9 @@ With the prebuild set to be updated on each push, it means that if there are ver
|
||||
|
||||
For example, let's imagine 5 pushes are made, in quick succession, against a branch that has a prebuild configuration. In this situation:
|
||||
|
||||
- A workflow run is started for the first push, to update the prebuild.
|
||||
- If the 4 remaining pushes do not affect the dev container configuration, the workflow runs for these are queued in a "pending" state.
|
||||
* A workflow run is started for the first push, to update the prebuild.
|
||||
* If the 4 remaining pushes do not affect the dev container configuration, the workflow runs for these are queued in a "pending" state.
|
||||
|
||||
If any of the remaining 4 pushes change the dev container configuration, then the service will not skip that one and will immediately run the prebuild creation workflow, updating the prebuild accordingly if it succeeds.
|
||||
|
||||
- Once the first run completes, workflow runs for pushes 2, 3, and 4 will be canceled, and the last queued workflow (for push 5) will run and update the prebuild.
|
||||
* Once the first run completes, workflow runs for pushes 2, 3, and 4 will be canceled, and the last queued workflow (for push 5) will run and update the prebuild.
|
||||
|
||||
@@ -23,8 +23,8 @@ You can configure read access to other {% data variables.product.prodname_dotcom
|
||||
|
||||
**Notes**:
|
||||
|
||||
- You can only authorize read permissions in this way, and the owner of the target repository must be the same as the owner of the repository for which you're creating a prebuild. For example, if you're creating a prebuild configuration for the `octo-org/octocatrepository`, then you'll be able to grant read permissions for other repositories, such `asocto-org/octodemo`, if this is specified in the `devcontainer.json` file, and provided you have the permissions yourself.
|
||||
- You can't use wildcards to specify repositories. You must define permissions for each repository for which you want to grant access.
|
||||
* You can only authorize read permissions in this way, and the owner of the target repository must be the same as the owner of the repository for which you're creating a prebuild. For example, if you're creating a prebuild configuration for the `octo-org/octocatrepository`, then you'll be able to grant read permissions for other repositories, such `asocto-org/octodemo`, if this is specified in the `devcontainer.json` file, and provided you have the permissions yourself.
|
||||
* You can't use wildcards to specify repositories. You must define permissions for each repository for which you want to grant access.
|
||||
|
||||
{% endnote %}
|
||||
|
||||
@@ -63,5 +63,5 @@ The {% data variables.product.pat_generic %} will be used for all subsequent pre
|
||||
|
||||
## Further reading
|
||||
|
||||
- "[AUTOTITLE](/codespaces/prebuilding-your-codespaces/configuring-prebuilds)"
|
||||
- "[AUTOTITLE](/codespaces/troubleshooting/troubleshooting-prebuilds)"
|
||||
* "[AUTOTITLE](/codespaces/prebuilding-your-codespaces/configuring-prebuilds)"
|
||||
* "[AUTOTITLE](/codespaces/troubleshooting/troubleshooting-prebuilds)"
|
||||
|
||||
@@ -56,10 +56,10 @@ For repositories owned by an organization, you can set up prebuilds if the organ
|
||||
|
||||
1. Choose how you want to automatically trigger prebuild updates.
|
||||
|
||||
- **Every push** (the default setting) - With this setting, prebuilds 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.
|
||||
* **Every push** (the default setting) - With this setting, prebuilds 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, prebuilds will be updated every time any of the following files is changed:
|
||||
- `.devcontainer/devcontainer.json`
|
||||
* **On configuration change** - With this setting, prebuilds will be updated every time any of the following files is changed:
|
||||
* `.devcontainer/devcontainer.json`
|
||||
|
||||
{% note %}
|
||||
|
||||
@@ -67,11 +67,11 @@ For repositories owned by an organization, you can set up prebuilds if the organ
|
||||
|
||||
{% endnote %}
|
||||
|
||||
- The Dockerfile referenced in the `build.dockerfile` property of the `.devcontainer/devcontainer.json` file.
|
||||
* The Dockerfile referenced in the `build.dockerfile` property of the `.devcontainer/devcontainer.json` file.
|
||||
|
||||
This setting ensures that changes to the dev container configuration files for the repository are used when a codespace is generated from a prebuild. The {% data variables.product.prodname_actions %} workflow that updates the prebuilds will run less often, so this option will use fewer {% data variables.product.prodname_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 prebuilds updated on a custom schedule that's defined by you. This can reduce consumption of {% data variables.product.prodname_actions %} minutes, however, with this option, codespaces may be created that do not use the latest dev container configuration changes.
|
||||
* **Scheduled** - With this setting, you can have your prebuilds updated on a custom schedule that's defined by you. This can reduce consumption of {% data variables.product.prodname_actions %} minutes, however, with this option, codespaces may be created that do not use the latest dev container configuration changes.
|
||||
|
||||
|
||||
|
||||
@@ -84,8 +84,8 @@ For repositories owned by an organization, you can set up prebuilds if the organ
|
||||
{% note %}
|
||||
|
||||
**Notes**:
|
||||
- The prebuild in each region incurs individual storage charges. You should, therefore, only enable prebuilds for regions in which you know they'll be used. For more information, see "[AUTOTITLE](/billing/managing-billing-for-github-codespaces/about-billing-for-github-codespaces#about-billing-for-codespaces-prebuilds)."
|
||||
- Developers can set their default region for {% data variables.product.prodname_github_codespaces %}, which can allow you to enable prebuilds for fewer regions. For more information, see "[AUTOTITLE](/codespaces/setting-your-user-preferences/setting-your-default-region-for-github-codespaces)."
|
||||
* The prebuild in each region incurs individual storage charges. You should, therefore, only enable prebuilds for regions in which you know they'll be used. For more information, see "[AUTOTITLE](/billing/managing-billing-for-github-codespaces/about-billing-for-github-codespaces#about-billing-for-codespaces-prebuilds)."
|
||||
* Developers can set their default region for {% data variables.product.prodname_github_codespaces %}, which can allow you to enable prebuilds for fewer regions. For more information, see "[AUTOTITLE](/codespaces/setting-your-user-preferences/setting-your-default-region-for-github-codespaces)."
|
||||
|
||||
{% endnote %}
|
||||
|
||||
@@ -139,5 +139,5 @@ You can use the `onCreateCommand` and `updateContentCommand` commands in your `d
|
||||
|
||||
## Further reading
|
||||
|
||||
- "[AUTOTITLE](/codespaces/prebuilding-your-codespaces/allowing-a-prebuild-to-access-other-repositories)"
|
||||
- "[AUTOTITLE](/codespaces/troubleshooting/troubleshooting-prebuilds)"
|
||||
* "[AUTOTITLE](/codespaces/prebuilding-your-codespaces/allowing-a-prebuild-to-access-other-repositories)"
|
||||
* "[AUTOTITLE](/codespaces/troubleshooting/troubleshooting-prebuilds)"
|
||||
|
||||
@@ -17,11 +17,11 @@ The prebuilds that you configure for a repository are created and updated using
|
||||
|
||||
Depending on the settings in a prebuild configuration, the workflow to update the prebuild may be triggered by these events:
|
||||
|
||||
- Creating or updating the prebuild configuration
|
||||
- Pushing a commit or a pull request to a branch that's configured to have prebuilds
|
||||
- Changing any of the dev container configuration files
|
||||
- A schedule that you've defined in the prebuild configuration
|
||||
- Manually triggering the workflow
|
||||
* Creating or updating the prebuild configuration
|
||||
* Pushing a commit or a pull request to a branch that's configured to have prebuilds
|
||||
* Changing any of the dev container configuration files
|
||||
* A schedule that you've defined in the prebuild configuration
|
||||
* Manually triggering the workflow
|
||||
|
||||
The settings in the prebuild configuration determine which events automatically trigger an update of the prebuild. For more information, see "[AUTOTITLE](/codespaces/prebuilding-your-codespaces/configuring-prebuilds#configuring-prebuilds)."
|
||||
|
||||
@@ -103,4 +103,4 @@ It may be useful to manually trigger a workflow run for a prebuild configuration
|
||||
|
||||
## Further reading
|
||||
|
||||
- "[AUTOTITLE](/codespaces/troubleshooting/troubleshooting-prebuilds)"
|
||||
* "[AUTOTITLE](/codespaces/troubleshooting/troubleshooting-prebuilds)"
|
||||
|
||||
Reference in New Issue
Block a user