Delete orphaned files (2025-07-21-16-29) (#56746)
Co-authored-by: John Clement <70238417+jclement136@users.noreply.github.com>
This commit is contained in:
docs-bot
@@ -1,19 +0,0 @@
|
||||
To remove specific configurations defined in the matrix, use `jobs.<job_id>.strategy.matrix.exclude`. An excluded configuration only has to be a partial match for it to be excluded. For example, the following workflow will run nine jobs: one job for each of the 12 configurations, minus the one excluded job that matches `{os: macos-latest, version: 12, environment: production}`, and the two excluded jobs that match `{os: windows-latest, version: 16}`.
|
||||
|
||||
```yaml
|
||||
strategy:
|
||||
matrix:
|
||||
os: [macos-latest, windows-latest]
|
||||
version: [12, 14, 16]
|
||||
environment: [staging, production]
|
||||
exclude:
|
||||
- os: macos-latest
|
||||
version: 12
|
||||
environment: production
|
||||
- os: windows-latest
|
||||
version: 16
|
||||
runs-on: {% raw %}${{ matrix.os }}{% endraw %}
|
||||
```
|
||||
|
||||
> [!NOTE]
|
||||
> All `include` combinations are processed after `exclude`. This allows you to use `include` to add back combinations that were previously excluded.
|
||||
@@ -1,30 +0,0 @@
|
||||
You can use contexts to create matrices. For more information about contexts, see [AUTOTITLE](/actions/learn-github-actions/contexts).
|
||||
|
||||
For example, the following workflow triggers on the `repository_dispatch` event and uses information from the event payload to build the matrix. When a repository dispatch event is created with a payload like the one below, the matrix `version` variable will have a value of `[12, 14, 16]`. For more information about the `repository_dispatch` trigger, see [AUTOTITLE](/actions/using-workflows/events-that-trigger-workflows#repository_dispatch).
|
||||
|
||||
```json
|
||||
{
|
||||
"event_type": "test",
|
||||
"client_payload": {
|
||||
"versions": [12, 14, 16]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
```yaml
|
||||
on:
|
||||
repository_dispatch:
|
||||
types:
|
||||
- test
|
||||
|
||||
jobs:
|
||||
example_matrix:
|
||||
runs-on: ubuntu-latest
|
||||
strategy:
|
||||
matrix:
|
||||
version: {% raw %}${{ github.event.client_payload.versions }}{% endraw %}
|
||||
steps:
|
||||
- uses: {% data reusables.actions.action-setup-node %}
|
||||
with:
|
||||
node-version: {% raw %}${{ matrix.version }}{% endraw %}
|
||||
```
|
||||
@@ -1,38 +0,0 @@
|
||||
Use `jobs.<job_id>.strategy.matrix.include` to expand existing matrix configurations or to add new configurations. The value of `include` is a list of objects.
|
||||
|
||||
For each object in the `include` list, the key:value pairs in the object will be added to each of the matrix combinations if none of the key:value pairs overwrite any of the original matrix values. If the object cannot be added to any of the matrix combinations, a new matrix combination will be created instead. Note that the original matrix values will not be overwritten, but added matrix values can be overwritten.
|
||||
|
||||
For example, this matrix:
|
||||
|
||||
```yaml
|
||||
strategy:
|
||||
matrix:
|
||||
fruit: [apple, pear]
|
||||
animal: [cat, dog]
|
||||
include:
|
||||
- color: green
|
||||
- color: pink
|
||||
animal: cat
|
||||
- fruit: apple
|
||||
shape: circle
|
||||
- fruit: banana
|
||||
- fruit: banana
|
||||
animal: cat
|
||||
```
|
||||
|
||||
will result in six jobs with the following matrix combinations:
|
||||
|
||||
* `{fruit: apple, animal: cat, color: pink, shape: circle}`
|
||||
* `{fruit: apple, animal: dog, color: green, shape: circle}`
|
||||
* `{fruit: pear, animal: cat, color: pink}`
|
||||
* `{fruit: pear, animal: dog, color: green}`
|
||||
* `{fruit: banana}`
|
||||
* `{fruit: banana, animal: cat}`
|
||||
|
||||
following this logic:
|
||||
|
||||
* `{color: green}` is added to all of the original matrix combinations because it can be added without overwriting any part of the original combinations.
|
||||
* `{color: pink, animal: cat}` adds `color:pink` only to the original matrix combinations that include `animal: cat`. This overwrites the `color: green` that was added by the previous `include` entry.
|
||||
* `{fruit: apple, shape: circle}` adds `shape: circle` only to the original matrix combinations that include `fruit: apple`.
|
||||
* `{fruit: banana}` cannot be added to any original matrix combination without overwriting a value, so it is added as an additional matrix combination.
|
||||
* `{fruit: banana, animal: cat}` cannot be added to any original matrix combination without overwriting a value, so it is added as an additional matrix combination. It does not add to the `{fruit: banana}` matrix combination because that combination was not one of the original matrix combinations.
|
||||
@@ -1,61 +0,0 @@
|
||||
You can use the output from one job to define matrices for multiple jobs.
|
||||
|
||||
For example, the following workflow demonstrates how to define a matrix of values in one job, use that matrix in a second jobs to produce artifacts, and then consume those artifacts in a third job. Each artifact is associated with a value from the matrix.
|
||||
|
||||
```yaml copy
|
||||
name: shared matrix
|
||||
on:
|
||||
push:
|
||||
workflow_dispatch:
|
||||
|
||||
jobs:
|
||||
define-matrix:
|
||||
runs-on: ubuntu-latest
|
||||
|
||||
outputs:
|
||||
colors: {% raw %}${{ steps.colors.outputs.colors }}{% endraw %}
|
||||
|
||||
steps:
|
||||
- name: Define Colors
|
||||
id: colors
|
||||
run: |
|
||||
echo 'colors=["red", "green", "blue"]' >> "$GITHUB_OUTPUT"
|
||||
|
||||
produce-artifacts:
|
||||
runs-on: ubuntu-latest
|
||||
needs: define-matrix
|
||||
strategy:
|
||||
matrix:
|
||||
color: {% raw %}${{ fromJSON(needs.define-matrix.outputs.colors) }}{% endraw %}
|
||||
|
||||
steps:
|
||||
- name: Define Color
|
||||
env:
|
||||
color: {% raw %}${{ matrix.color }}{% endraw %}
|
||||
run: |
|
||||
echo "$color" > color
|
||||
- name: Produce Artifact
|
||||
uses: {% data reusables.actions.action-upload-artifact %}
|
||||
with:
|
||||
name: {% raw %}${{ matrix.color }}{% endraw %}
|
||||
path: color
|
||||
|
||||
consume-artifacts:
|
||||
runs-on: ubuntu-latest
|
||||
needs:
|
||||
- define-matrix
|
||||
- produce-artifacts
|
||||
strategy:
|
||||
matrix:
|
||||
color: {% raw %}${{ fromJSON(needs.define-matrix.outputs.colors) }}{% endraw %}
|
||||
|
||||
steps:
|
||||
- name: Retrieve Artifact
|
||||
uses: {% data reusables.actions.action-download-artifact %}
|
||||
with:
|
||||
name: {% raw %}${{ matrix.color }}{% endraw %}
|
||||
|
||||
- name: Report Color
|
||||
run: |
|
||||
cat color
|
||||
```
|
||||
@@ -1,50 +0,0 @@
|
||||
You can specify multiple variables to create a multi-dimensional matrix. A job will run for each possible combination of the variables.
|
||||
|
||||
For example, the following workflow specifies two variables:
|
||||
|
||||
* Two operating systems specified in the `os` variable
|
||||
* Three Node.js versions specified in the `version` variable
|
||||
|
||||
The workflow will run six jobs, one for each combination of the `os` and `version` variables. Each job will set the `runs-on` value to the current `os` value and will pass the current `version` value to the `actions/setup-node` action.
|
||||
|
||||
```yaml
|
||||
jobs:
|
||||
example_matrix:
|
||||
strategy:
|
||||
matrix:
|
||||
os: [ubuntu-22.04, ubuntu-20.04]
|
||||
version: [10, 12, 14]
|
||||
runs-on: {% raw %}${{ matrix.os }}{% endraw %}
|
||||
steps:
|
||||
- uses: {% data reusables.actions.action-setup-node %}
|
||||
with:
|
||||
node-version: {% raw %}${{ matrix.version }}{% endraw %}
|
||||
```
|
||||
|
||||
A variable configuration in a matrix can be an `array` of `object`s.
|
||||
|
||||
```yaml
|
||||
matrix:
|
||||
os:
|
||||
- ubuntu-latest
|
||||
- macos-latest
|
||||
node:
|
||||
- version: 14
|
||||
- version: 20
|
||||
env: NODE_OPTIONS=--openssl-legacy-provider
|
||||
```
|
||||
|
||||
This matrix produces 4 jobs with corresponding contexts.
|
||||
|
||||
```yaml
|
||||
- matrix.os: ubuntu-latest
|
||||
matrix.node.version: 14
|
||||
- matrix.os: ubuntu-latest
|
||||
matrix.node.version: 20
|
||||
matrix.node.env: NODE_OPTIONS=--openssl-legacy-provider
|
||||
- matrix.os: macos-latest
|
||||
matrix.node.version: 14
|
||||
- matrix.os: macos-latest
|
||||
matrix.node.version: 20
|
||||
matrix.node.env: NODE_OPTIONS=--openssl-legacy-provider
|
||||
```
|
||||
@@ -1,13 +0,0 @@
|
||||
By default, {% data variables.product.github %} will maximize the number of jobs run in parallel depending on runner availability. To set the maximum number of jobs that can run simultaneously when using a `matrix` job strategy, use `jobs.<job_id>.strategy.max-parallel`.
|
||||
|
||||
For example, the following workflow will run a maximum of two jobs at a time, even if there are runners available to run all six jobs at once.
|
||||
|
||||
```yaml
|
||||
jobs:
|
||||
example_matrix:
|
||||
strategy:
|
||||
max-parallel: 2
|
||||
matrix:
|
||||
version: [10, 12, 14]
|
||||
os: [ubuntu-latest, windows-latest]
|
||||
```
|
||||
@@ -1,15 +0,0 @@
|
||||
You can specify a single variable to create a single-dimension matrix.
|
||||
|
||||
For example, the following workflow defines the variable `version` with the values `[10, 12, 14]`. The workflow will run three jobs, one for each value in the variable. Each job will access the `version` value through the `matrix.version` context and pass the value as `node-version` to the `actions/setup-node` action.
|
||||
|
||||
```yaml
|
||||
jobs:
|
||||
example_matrix:
|
||||
strategy:
|
||||
matrix:
|
||||
version: [10, 12, 14]
|
||||
steps:
|
||||
- uses: {% data reusables.actions.action-setup-node %}
|
||||
with:
|
||||
node-version: {% raw %}${{ matrix.version }}{% endraw %}
|
||||
```
|
||||
@@ -1,25 +0,0 @@
|
||||
Use `jobs.<job_id>.strategy.matrix` to define a matrix of different job configurations. Within your matrix, define one or more variables followed by an array of values. For example, the following matrix has a variable called `version` with the value `[10, 12, 14]` and a variable called `os` with the value `[ubuntu-latest, windows-latest]`:
|
||||
|
||||
```yaml
|
||||
jobs:
|
||||
example_matrix:
|
||||
strategy:
|
||||
matrix:
|
||||
version: [10, 12, 14]
|
||||
os: [ubuntu-latest, windows-latest]
|
||||
```
|
||||
|
||||
A job will run for each possible combination of the variables. In this example, the workflow will run six jobs, one for each combination of the `os` and `version` variables.
|
||||
|
||||
By default, {% data variables.product.github %} will maximize the number of jobs run in parallel depending on runner availability. The order of the variables in the matrix determines the order in which the jobs are created. The first variable you define will be the first job that is created in your workflow run. For example, the above matrix will create the jobs in the following order:
|
||||
|
||||
* `{version: 10, os: ubuntu-latest}`
|
||||
* `{version: 10, os: windows-latest}`
|
||||
* `{version: 12, os: ubuntu-latest}`
|
||||
* `{version: 12, os: windows-latest}`
|
||||
* `{version: 14, os: ubuntu-latest}`
|
||||
* `{version: 14, os: windows-latest}`
|
||||
|
||||
A matrix will generate a maximum of 256 jobs per workflow run. This limit applies to both {% data variables.product.github %}-hosted and self-hosted runners.
|
||||
|
||||
The variables that you define become properties in the `matrix` context, and you can reference the property in other areas of your workflow file. In this example, you can use `matrix.version` and `matrix.os` to access the current value of `version` and `os` that the job is using. For more information, see [AUTOTITLE](/actions/learn-github-actions/contexts).
|
||||
@@ -1 +0,0 @@
|
||||
{% ifversion ghes or ghec %}You can share workflows with your organization, publicly or privately, by calling{% else %} You can call{% endif %} one workflow from within another workflow. This allows you to reuse workflows, avoiding duplication and making your workflows easier to maintain. For more information, see [AUTOTITLE](/actions/using-workflows/reusing-workflows).
|
||||
@@ -1 +0,0 @@
|
||||
* **API requests** - You can execute up to {% ifversion ghec %}15,000{% else %}1,000{% endif %} requests to the GitHub API in an hour across all actions within a repository. If requests are exceeded, additional API calls will fail which might cause jobs to fail.
|
||||
@@ -1 +0,0 @@
|
||||
A job matrix can generate a maximum of 256 jobs per workflow run. This limit applies to both {% data variables.product.github %}-hosted and self-hosted runners.
|
||||
@@ -1 +0,0 @@
|
||||
* **Workflow run queue** - No more than 500 workflow runs can be queued in a 10 second interval per repository. If a workflow run reaches this limit, the workflow run is terminated and fails to complete.
|
||||
@@ -1 +0,0 @@
|
||||
* **Workflow run time** - Each workflow run is limited to 35 days. If a workflow run reaches this limit, the workflow run is cancelled. This period includes execution duration, and time spent on waiting and approval.
|
||||
@@ -1 +0,0 @@
|
||||
When you enable {% data variables.product.prodname_code_scanning %} on pull requests, the check fails only if one or more alerts of severity `error`, or security severity `critical` or `high` are detected. The check will succeed if alerts with lower severities or security severities are detected. For important codebases, you may want the {% data variables.product.prodname_code_scanning %} check to fail if any alerts are detected, so that the alert must be fixed or dismissed before the code change is merged. For more information about severity levels, see [About alert severity and security severity levels](/code-security/code-scanning/managing-code-scanning-alerts/about-code-scanning-alerts#about-alert-severity-and-security-severity-levels).
|
||||
@@ -1,3 +0,0 @@
|
||||
When an organization owner assigns a {% data variables.product.prodname_copilot_short %} license to a member of their organization, the user's access to features and models is controlled by policies.
|
||||
|
||||
Enterprise owners can define a policy for the whole enterprise, or delegate the decision to individual organization owners. See [AUTOTITLE](/copilot/concepts/policies).
|
||||
@@ -1 +0,0 @@
|
||||
1. In the sidebar, under "Code, planning, and automation", click **{% octicon "copilot" aria-hidden="true" aria-label="copilot" %} {% data variables.product.prodname_copilot_short %}**, and then click **Policies**.
|
||||
@@ -1,9 +0,0 @@
|
||||
Each {% data variables.product.prodname_copilot_short %} plan includes a per-user allowance for premium requests:
|
||||
|
||||
* 300 requests per user per month for {% data variables.copilot.copilot_business_short %}
|
||||
* 1000 requests per user per month for {% data variables.copilot.copilot_enterprise_short %}
|
||||
|
||||
{% data variables.copilot.copilot_chat_short %}, {% data variables.copilot.copilot_agent_short %} mode, {% data variables.copilot.copilot_coding_agent %}, {% data variables.product.prodname_copilot_short %} code review, and {% data variables.copilot.copilot_extensions_short %} use premium requests, with usage varying by model.
|
||||
|
||||
> [!TIP]
|
||||
> {% data variables.copilot.copilot_coding_agent %} uses {% data variables.product.prodname_actions %} in addition to premium requests. For more information, see [AUTOTITLE](/billing/managing-billing-for-your-products/managing-billing-for-github-actions/managing-your-spending-limit-for-github-actions).
|
||||
@@ -1 +0,0 @@
|
||||
You can configure {% data variables.product.prodname_copilot %} to generate responses that are tailored to the way your team works, the tools you use, or the specifics of your project.
|
||||
@@ -1 +0,0 @@
|
||||
You can only create groups for {% data variables.product.prodname_dependabot_version_updates %}. {% data variables.product.prodname_dependabot_security_updates %} do not support grouped updates. In addition, if there is a grouped pull request for a vulnerable package, {% data variables.product.prodname_dependabot_security_updates %} will always attempt to create a separate pull request, even if the existing group pull request is an update to the same, or a later, version.
|
||||
@@ -1 +0,0 @@
|
||||
On an instance in a cluster configuration, restoration of a backup using `ghe-restore` will exit prematurely if Redis has not restarted properly.
|
||||
@@ -1 +0,0 @@
|
||||
You must create and use a dedicated machine user account on your IdP to associate with an enterprise owner account on {% data variables.product.github %}. Store the credentials for the user account securely in a password manager. For more information, see [AUTOTITLE](/admin/identity-and-access-management/using-saml-for-enterprise-iam/configuring-user-provisioning-with-scim-for-your-enterprise#enabling-user-provisioning-for-your-enterprise).
|
||||
@@ -1 +0,0 @@
|
||||
You must configure SAML SSO for {% data variables.location.product_location %}. For more information, see [AUTOTITLE](/admin/identity-and-access-management/using-saml-for-enterprise-iam/configuring-saml-single-sign-on-for-your-enterprise).
|
||||
@@ -1 +0,0 @@
|
||||
> [!NOTE] The security overview dashboard is currently in {% data variables.release-phases.public_preview %} and subject to change.
|
||||
Reference in New Issue
Block a user