Merge branch 'universe-2022-megabranch' into jules-new-8018
This commit is contained in:
6
data/features/security-overview-alert-views.yml
Normal file
6
data/features/security-overview-alert-views.yml
Normal file
@@ -0,0 +1,6 @@
|
||||
# Reference: #5503.
|
||||
# Documentation for the security overview individual views for each type of security alert
|
||||
versions:
|
||||
ghes: '> 3.4'
|
||||
ghae: '>= 3.5'
|
||||
ghec: '*'
|
||||
@@ -1,6 +0,0 @@
|
||||
# Reference: #5503.
|
||||
# Documentation for the security overview individual views
|
||||
versions:
|
||||
ghes: '> 3.4'
|
||||
ghae: '>= 3.5'
|
||||
ghec: '*'
|
||||
7
data/features/target-runner-groups.yml
Normal file
7
data/features/target-runner-groups.yml
Normal file
@@ -0,0 +1,7 @@
|
||||
# Reference: #8268
|
||||
# Restrict workflow using runner group names
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghec: '*'
|
||||
ghes: '>= 3.8'
|
||||
ghae: '>= 3.8'
|
||||
17
data/reusables/actions/jobs/example-runs-on-groups.md
Normal file
17
data/reusables/actions/jobs/example-runs-on-groups.md
Normal file
@@ -0,0 +1,17 @@
|
||||
In this example, Ubuntu 16-core runners have been added to a group called `ubuntu-runners`. The `runs-on` key sends the job to any available runner in the `ubuntu-runners` group:
|
||||
|
||||
```yaml
|
||||
name: learn-github-actions
|
||||
on: [push]
|
||||
jobs:
|
||||
check-bats-version:
|
||||
runs-on:
|
||||
group: ubuntu-runners
|
||||
steps:
|
||||
- uses: {% data reusables.actions.action-checkout %}
|
||||
- uses: {% data reusables.actions.action-setup-node %}
|
||||
with:
|
||||
node-version: '14'
|
||||
- run: npm install -g bats
|
||||
- run: bats -v
|
||||
```
|
||||
@@ -0,0 +1,20 @@
|
||||
When you combine groups and labels, the runner must meet both requirements to be eligible to run the job.
|
||||
|
||||
In this example, a runner group called `ubuntu-runners` is populated with Ubuntu 16-core runners, which have also been assigned the label `ubuntu-20.04-16core`. The `runs-on` key combines `group` and `labels` so that the job is routed to any available runner within the group that also has a matching label:
|
||||
|
||||
```yaml
|
||||
name: learn-github-actions
|
||||
on: [push]
|
||||
jobs:
|
||||
check-bats-version:
|
||||
runs-on:
|
||||
group: ubuntu-runners
|
||||
labels: ubuntu-20.04-16core
|
||||
steps:
|
||||
- uses: {% data reusables.actions.action-checkout %}
|
||||
- uses: {% data reusables.actions.action-setup-node %}
|
||||
with:
|
||||
node-version: '14'
|
||||
- run: npm install -g bats
|
||||
- run: bats -v
|
||||
```
|
||||
@@ -1,5 +1,12 @@
|
||||
Use `jobs.<job_id>.runs-on` to define the type of machine to run the job on. {% ifversion fpt or ghec %}The machine can be either a {% data variables.product.prodname_dotcom %}-hosted runner or a self-hosted runner.{% endif %} You can provide `runs-on` as a single string or as an array of strings. If you specify an array of strings, your workflow will run on a self-hosted runner whose labels match all of the specified `runs-on` values, if available. If you would like to run your workflow on multiple machines, use [`jobs.<job_id>.strategy`](/actions/learn-github-actions/workflow-syntax-for-github-actions#jobsjob_idstrategy).
|
||||
Use `jobs.<job_id>.runs-on` to define the type of machine to run the job on.
|
||||
|
||||
{% ifversion fpt or ghec %}- The destination machine can be either a [{% data variables.product.prodname_dotcom %}-hosted runner](#choosing-github-hosted-runners), [{% data variables.actions.hosted_runner %}](#choosing-runners-in-a-group), or a [self-hosted runner](#choosing-self-hosted-runners).{% else %}
|
||||
- The destination machine can be a [self-hosted runner](#choosing-self-hosted-runners).{% endif %}
|
||||
{% ifversion target-runner-groups %}- You can target runners based on the labels assigned to them, or their group membership, or a combination of these.{% else %}
|
||||
- You can target runners based on the labels assigned to them.{% endif %}
|
||||
- You can provide `runs-on` as a single string or as an array of strings.
|
||||
- If you specify an array of strings, your workflow will execute on any runner that matches all of the specified `runs-on` values.
|
||||
- If you would like to run your workflow on multiple machines, use [`jobs.<job_id>.strategy`](/actions/learn-github-actions/workflow-syntax-for-github-actions#jobsjob_idstrategy).
|
||||
|
||||
{% ifversion fpt or ghec or ghes %}
|
||||
{% data reusables.actions.enterprise-github-hosted-runners %}
|
||||
@@ -34,3 +41,21 @@ runs-on: [self-hosted, linux]
|
||||
```
|
||||
|
||||
For more information, see "[About self-hosted runners](/github/automating-your-workflow-with-github-actions/about-self-hosted-runners)" and "[Using self-hosted runners in a workflow](/github/automating-your-workflow-with-github-actions/using-self-hosted-runners-in-a-workflow)."
|
||||
|
||||
{% ifversion target-runner-groups %}
|
||||
|
||||
### Choosing runners in a group
|
||||
|
||||
You can use `runs-on` to target runner groups, so that the job will execute on any runner that is a member of that group. For more granular control, you can also combine runner groups with labels.
|
||||
|
||||
Runner groups can only have [{% data variables.actions.hosted_runner %}s](/actions/using-github-hosted-runners/using-larger-runners) or [self-hosted runners](/actions/hosting-your-own-runners) as members.
|
||||
|
||||
#### Example: Using groups to control where jobs are run
|
||||
|
||||
{% data reusables.actions.jobs.example-runs-on-groups %}
|
||||
|
||||
#### Example: Combining groups and labels
|
||||
|
||||
{% data reusables.actions.jobs.example-runs-on-labels-and-groups %}
|
||||
|
||||
{% endif %}
|
||||
@@ -0,0 +1,34 @@
|
||||
|
||||
{% ifversion target-runner-groups %}{% ifversion ghec or ghae or ghes %}
|
||||
## Using unique names for runner groups
|
||||
|
||||
{% data variables.product.prodname_actions %} requires that runner group names must be unique at the organization level. This means that an organization will no longer be able to create a runner group with the same name as one in the enterprise. In addition, users will see a warning banner on any runner groups that share the same name as a group in the enterprise, suggesting that the organization group should be renamed.
|
||||
|
||||
To avoid ambiguity, a workflow will fail if there are duplicate runner groups in the organization and enterprise. To address this, you can either rename one of your runner groups in the organization or enterprise, or you can update your workflow file to add a prefix to the runner group name:
|
||||
|
||||
- `org/` or `organization/`
|
||||
- `ent/` or `enterprise/`
|
||||
|
||||
### Example: Using prefixes to differentiate runner groups
|
||||
|
||||
For example, if you have a runner group named `my-group` in the organization and another named `my-group` in the enterprise, you can update your workflow file to use `org/my-group` or `ent/my-group` to differentiate between the two.
|
||||
|
||||
Using `org/`:
|
||||
|
||||
```yaml
|
||||
runs-on:
|
||||
group: org/my-group
|
||||
labels: [ self-hosted, label-1 ]
|
||||
```
|
||||
|
||||
Using `ent/`:
|
||||
|
||||
```yaml
|
||||
runs-on:
|
||||
group: ent/my-group
|
||||
labels: [ self-hosted, label-1 ]
|
||||
```
|
||||
|
||||
{% endif %}
|
||||
|
||||
{% endif %}
|
||||
@@ -1,5 +0,0 @@
|
||||
{% note %}
|
||||
|
||||
**Note**: The {% data variables.product.prodname_github_codespaces %} API is currently in public beta and subject to change.
|
||||
|
||||
{% endnote %}
|
||||
Reference in New Issue
Block a user