1
0
mirror of synced 2026-01-07 09:01:31 -05:00

Merge branch 'main' into packages-azure-storage-note

This commit is contained in:
sanjeevh93
2022-04-27 10:31:37 +05:30
committed by GitHub
361 changed files with 2531 additions and 1451 deletions

View File

@@ -23,6 +23,6 @@ jobs:
steps:
- uses: alex-page/github-project-automation-plus@bb266ff4dde9242060e2d5418e120a133586d488
with:
project: Docs team reviews
project: Docs open source board
column: Help wanted
repo-token: ${{ secrets.DOCUBOT_READORG_REPO_WORKFLOW_SCOPES }}

View File

@@ -57,7 +57,7 @@ jobs:
uses: EndBug/add-and-commit@050a66787244b10a4874a2a5f682130263edc192
with:
# The arguments for the `git add` command
add: '["lib/rest/static/apps", "lib/rest/static/decorated"]'
add: '["lib/rest/static/apps", "lib/rest/static/decorated", "lib/redirects/static/client-side-rest-api-redirects.json"]'
# The message for the commit
message: 'Add decorated OpenAPI schema files'

Binary file not shown.

Before

Width:  |  Height:  |  Size: 60 KiB

After

Width:  |  Height:  |  Size: 65 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 32 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 86 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 53 KiB

After

Width:  |  Height:  |  Size: 96 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 83 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 16 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 122 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 42 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 9.7 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 66 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 103 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 105 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 64 KiB

View File

@@ -65,7 +65,7 @@ The examples below demonstrate using the `fwal/setup-swift` action.
### Using multiple Swift versions
You can configure your job to use a multiple versions of Swift in a build matrix.
You can configure your job to use multiple versions of Swift in a matrix.
```yaml{:copy}
{% data reusables.actions.actions-not-certified-by-github-comment %}

View File

@@ -23,7 +23,7 @@ miniTocMaxHeadingLevel: 3
Contexts are a way to access information about workflow runs, runner environments, jobs, and steps. Each context is an object that contains properties, which can be strings or other objects.
{% data reusables.actions.context-contents %} For example, the `matrix` context is only populated for jobs in a [build matrix](/actions/learn-github-actions/workflow-syntax-for-github-actions#jobsjob_idstrategymatrix).
{% data reusables.actions.context-contents %} For example, the `matrix` context is only populated for jobs in a [matrix](/actions/learn-github-actions/workflow-syntax-for-github-actions#jobsjob_idstrategymatrix).
You can access contexts using the expression syntax. For more information, see "[Expressions](/actions/learn-github-actions/expressions)."
@@ -552,19 +552,19 @@ The following example contents of the `secrets` context shows the automatic `GIT
## `strategy` context
For workflows with a build matrix, the `strategy` context contains information about the matrix execution strategy for the current job.
For workflows with a matrix, the `strategy` context contains information about the matrix execution strategy for the current job.
| Property name | Type | Description |
|---------------|------|-------------|
| `strategy` | `object` | This context changes for each job in a workflow run. You can access this context from any job or step in a workflow. This object contains all the properties listed below. |
| `strategy.fail-fast` | `string` | When `true`, all in-progress jobs are canceled if any job in a build matrix fails. For more information, see "[Workflow syntax for {% data variables.product.prodname_actions %}](/actions/learn-github-actions/workflow-syntax-for-github-actions#jobsjob_idstrategyfail-fast)." |
| `strategy.job-index` | `string` | The index of the current job in the build matrix. **Note:** This number is a zero-based number. The first job's index in the build matrix is `0`. |
| `strategy.job-total` | `string` | The total number of jobs in the build matrix. **Note:** This number **is not** a zero-based number. For example, for a build matrix with four jobs, the value of `job-total` is `4`. |
| `strategy.fail-fast` | `string` | When `true`, all in-progress jobs are canceled if any job in a matrix fails. For more information, see "[Workflow syntax for {% data variables.product.prodname_actions %}](/actions/learn-github-actions/workflow-syntax-for-github-actions#jobsjob_idstrategyfail-fast)." |
| `strategy.job-index` | `string` | The index of the current job in the matrix. **Note:** This number is a zero-based number. The first job's index in the matrix is `0`. |
| `strategy.job-total` | `string` | The total number of jobs in the matrix. **Note:** This number **is not** a zero-based number. For example, for a matrix with four jobs, the value of `job-total` is `4`. |
| `strategy.max-parallel` | `string` | The maximum number of jobs that can run simultaneously when using a `matrix` job strategy. For more information, see "[Workflow syntax for {% data variables.product.prodname_actions %}](/actions/learn-github-actions/workflow-syntax-for-github-actions#jobsjob_idstrategymax-parallel)." |
### Example contents of the `strategy` context
The following example contents of the `strategy` context is from a build matrix with four jobs, and is taken from the final job. Note the difference between the zero-based `job-index` number, and `job-total` which is not zero-based.
The following example contents of the `strategy` context is from a matrix with four jobs, and is taken from the final job. Note the difference between the zero-based `job-index` number, and `job-total` which is not zero-based.
```yaml
{
@@ -577,7 +577,7 @@ The following example contents of the `strategy` context is from a build matrix
### Example usage of the `strategy` context
This example workflow uses the `strategy.job-index` property to set a unique name for a log file for each job in a build matrix.
This example workflow uses the `strategy.job-index` property to set a unique name for a log file for each job in a matrix.
```yaml{:copy}
name: Test matrix
@@ -602,18 +602,18 @@ jobs:
## `matrix` context
For workflows with a build matrix, the `matrix` context contains the matrix properties defined in the workflow file that apply to the current job. For example, if you configure a build matrix with the `os` and `node` keys, the `matrix` context object includes the `os` and `node` properties with the values that are being used for the current job.
For workflows with a matrix, the `matrix` context contains the matrix properties defined in the workflow file that apply to the current job. For example, if you configure a matrix with the `os` and `node` keys, the `matrix` context object includes the `os` and `node` properties with the values that are being used for the current job.
There are no standard properties in the `matrix` context, only those which are defined in the workflow file.
| Property name | Type | Description |
|---------------|------|-------------|
| `matrix` | `object` | This context is only available for jobs in a build matrix, and changes for each job in a workflow run. You can access this context from any job or step in a workflow. This object contains the properties listed below. |
| `matrix` | `object` | This context is only available for jobs in a matrix, and changes for each job in a workflow run. You can access this context from any job or step in a workflow. This object contains the properties listed below. |
| `matrix.<property_name>` | `string` | The value of a matrix property. |
### Example contents of the `matrix` context
The following example contents of the `matrix` context is from a job in a build matrix that has the `os` and `node` matrix properties defined in the workflow. The job is executing the matrix combination of an `ubuntu-latest` OS and Node.js version `16`.
The following example contents of the `matrix` context is from a job in a matrix that has the `os` and `node` matrix properties defined in the workflow. The job is executing the matrix combination of an `ubuntu-latest` OS and Node.js version `16`.
```yaml
{
@@ -624,7 +624,7 @@ The following example contents of the `matrix` context is from a job in a build
### Example usage of the `matrix` context
This example workflow creates a build matrix with `os` and `node` keys. It uses the `matrix.os` property to set the runner type for each job, and uses the `matrix.node` property to set the Node.js version for each job.
This example workflow creates a matrix with `os` and `node` keys. It uses the `matrix.os` property to set the runner type for each job, and uses the `matrix.node` property to set the Node.js version for each job.
```yaml{:copy}
name: Test matrix

View File

@@ -50,7 +50,7 @@ Both CircleCI and {% data variables.product.prodname_actions %} configure `jobs`
Both CircleCI and {% data variables.product.prodname_actions %} provide a mechanism to reuse and share tasks in a workflow. CircleCI uses a concept called orbs, written in YAML, to provide tasks that people can reuse in a workflow. {% data variables.product.prodname_actions %} has powerful and flexible reusable components called actions, which you build with either JavaScript files or Docker images. You can create actions by writing custom code that interacts with your repository in any way you'd like, including integrating with {% data variables.product.product_name %}'s APIs and any publicly available third-party API. For example, an action can publish npm modules, send SMS alerts when urgent issues are created, or deploy production-ready code. For more information, see "[Creating actions](/actions/creating-actions)."
CircleCI can reuse pieces of workflows with YAML anchors and aliases. {% data variables.product.prodname_actions %} supports the most common need for reusability using build matrixes. For more information about build matrixes, see "[Managing complex workflows](/actions/learn-github-actions/managing-complex-workflows/#using-a-build-matrix)."
CircleCI can reuse pieces of workflows with YAML anchors and aliases. {% data variables.product.prodname_actions %} supports the most common need for reusability using matrices. For more information about matrices, see "[Using a matrix for your jobs](/actions/using-jobs/using-a-matrix-for-your-jobs)."
## Using Docker images

View File

@@ -82,9 +82,9 @@ Jenkins can run the `stages` and `steps` in parallel, while {% data variables.pr
| ------------- | ------------- |
| [`parallel`](https://jenkins.io/doc/book/pipeline/syntax/#parallel) | [`jobs.<job_id>.strategy.max-parallel`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idstrategymax-parallel) |
### Build matrix
### Matrix
Both {% data variables.product.prodname_actions %} and Jenkins let you use a build matrix to define various system combinations.
Both {% data variables.product.prodname_actions %} and Jenkins let you use a matrix to define various system combinations.
| Jenkins | {% data variables.product.prodname_actions %} |
| ------------- | ------------- |

View File

@@ -60,9 +60,9 @@ Travis CI can use `stages` to run jobs in parallel. Similarly, {% data variables
Travis CI and {% data variables.product.prodname_actions %} both support status badges, which let you indicate whether a build is passing or failing.
For more information, see ["Adding a workflow status badge to your repository](/actions/managing-workflow-runs/adding-a-workflow-status-badge)."
### Using a build matrix
### Using a matrix
Travis CI and {% data variables.product.prodname_actions %} both support a build matrix, allowing you to perform testing using combinations of operating systems and software packages. For more information, see "[Using a build matrix](/actions/learn-github-actions/managing-complex-workflows#using-a-build-matrix)."
Travis CI and {% data variables.product.prodname_actions %} both support a matrix, allowing you to perform testing using combinations of operating systems and software packages. For more information, see "[Using a matrix for your jobs](/actions/using-jobs/using-a-matrix-for-your-jobs)."
Below is an example comparing the syntax for each system:

View File

@@ -13,7 +13,7 @@ children:
- /using-jobs-in-a-workflow
- /choosing-the-runner-for-a-job
- /using-conditions-to-control-job-execution
- /using-a-build-matrix-for-your-jobs
- /using-a-matrix-for-your-jobs
- /using-concurrency
- /using-environments-for-jobs
- /running-jobs-in-a-container

View File

@@ -1,30 +0,0 @@
---
title: Using a build matrix for your jobs
shortTitle: Using a build matrix for your jobs
intro: Create a build matrix and define variations for each job.
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
miniTocMaxHeadingLevel: 4
---
{% data reusables.actions.enterprise-beta %}
{% data reusables.actions.enterprise-github-hosted-runners %}
## Overview
{% data reusables.actions.jobs.section-using-a-build-matrix-for-your-jobs-strategy %}
## Creating a matrix of different job configurations
{% data reusables.actions.jobs.section-using-a-build-matrix-for-your-jobs-matrix %}
## Canceling remaining jobs if a `matrix` job fails
{% data reusables.actions.jobs.section-using-a-build-matrix-for-your-jobs-failfast %}
## Defining the maximum number of concurrent jobs in a `matrix`
{% data reusables.actions.jobs.section-using-a-build-matrix-for-your-jobs-max-parallel %}

View File

@@ -0,0 +1,60 @@
---
title: Using a matrix for your jobs
shortTitle: Using a matrix
intro: Create a matrix to define variations for each job.
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
miniTocMaxHeadingLevel: 4
redirect_from:
- /actions/using-jobs/using-a-build-matrix-for-your-jobs
---
{% data reusables.actions.enterprise-beta %}
{% data reusables.actions.enterprise-github-hosted-runners %}
## About matrix strategies
{% data reusables.actions.jobs.about-matrix-strategy %}
## Using a matrix strategy
{% data reusables.actions.jobs.using-matrix-strategy %}
### Example: Using a single-dimension matrix
{% data reusables.actions.jobs.single-dimension-matrix %}
### Example: Using a multi-dimension matrix
{% data reusables.actions.jobs.multi-dimension-matrix %}
### Example: Using contexts to create matrices
{% data reusables.actions.jobs.matrix-from-context %}
## Expanding or adding matrix configurations
{% data reusables.actions.jobs.matrix-include %}
### Example: Expanding configurations
{% data reusables.actions.jobs.matrix-expand-with-include %}
### Example: Adding configurations
{% data reusables.actions.jobs.matrix-add-with-include %}
## Excluding matrix configurations
{% data reusables.actions.jobs.matrix-exclude %}
## Handling failures
{% data reusables.actions.jobs.section-using-a-build-matrix-for-your-jobs-failfast %}
## Defining the maximum number of concurrent jobs
{% data reusables.actions.jobs.section-using-a-build-matrix-for-your-jobs-max-parallel %}

View File

@@ -105,9 +105,9 @@ jobs:
For more information, see "[Defining prerequisite jobs](/actions/using-jobs/using-jobs-in-a-workflow#defining-prerequisite-jobs)."
### Using a build matrix
### Using a matrix
You can use a build matrix if you want your workflow to run tests across multiple combinations of parameters, such as operating systems, platforms, and languages. The build matrix is created using the `strategy` keyword, which receives the build options as an array. For example, this build matrix will run the job multiple times, using different versions of Node.js:
{% data reusables.actions.jobs.about-matrix-strategy %} The matrix is created using the `strategy` keyword, which receives the build options as an array. For example, this matrix will run the job multiple times, using different versions of Node.js:
```yaml
jobs:
@@ -115,14 +115,14 @@ jobs:
runs-on: ubuntu-latest
strategy:
matrix:
node: [6, 8, 10]
node: [12, 14, 16]
steps:
- uses: {% data reusables.actions.action-setup-node %}
with:
node-version: {% raw %}${{ matrix.node }}{% endraw %}
```
For more information, see "[Using a build matrix for your jobs](/actions/using-jobs/using-a-build-matrix-for-your-jobs)."
For more information, see "[Using a matrix for your jobs](/actions/using-jobs/using-a-matrix-for-your-jobs)."
{% ifversion fpt or ghec %}
### Caching dependencies

View File

@@ -103,8 +103,13 @@ You can define inputs and secrets, which can be passed from the caller workflow
required: true
```
{% endraw %}
{% if actions-inherit-secrets-reusable-workflows %}
For details of the syntax for defining inputs and secrets, see [`on.workflow_call.inputs`](/actions/reference/workflow-syntax-for-github-actions#onworkflow_callinputs), [`on.workflow_call.secrets`](/actions/reference/workflow-syntax-for-github-actions#onworkflow_callsecrets) and [`on.workflow_call.secrets.inherit`](/actions/using-workflows/workflow-syntax-for-github-actions#onworkflow_callsecretsinherit).
1. In the reusable workflow, reference the input or secret that you defined in the `on` key in the previous step. If the secrets are inherited using `secrets: inherit`, you can reference them even if they are not defined in the `on` key.
{%else%}
For details of the syntax for defining inputs and secrets, see [`on.workflow_call.inputs`](/actions/reference/workflow-syntax-for-github-actions#onworkflow_callinputs) and [`on.workflow_call.secrets`](/actions/reference/workflow-syntax-for-github-actions#onworkflow_callsecrets).
1. In the reusable workflow, reference the input or secret that you defined in the `on` key in the previous step.
1. In the reusable workflow, reference the input or secret that you defined in the `on` key in the previous step.
{%endif%}
{% raw %}
```yaml
@@ -189,6 +194,7 @@ When you call a reusable workflow, you can only use the following keywords in th
* [`jobs.<job_id>.with.<input_id>`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idwithinput_id)
* [`jobs.<job_id>.secrets`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idsecrets)
* [`jobs.<job_id>.secrets.<secret_id>`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idsecretssecret_id)
{% if actions-inherit-secrets-reusable-workflows %}* [`jobs.<job_id>.secrets.inherit`](/actions/using-workflows/workflow-syntax-for-github-actions#onworkflow_callsecretsinherit){% endif %}
* [`jobs.<job_id>.needs`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idneeds)
* [`jobs.<job_id>.if`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idif)
* [`jobs.<job_id>.permissions`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idpermissions)

View File

@@ -157,6 +157,42 @@ jobs:
```
{% endraw %}
{% if actions-inherit-secrets-reusable-workflows %}
#### `on.workflow_call.secrets.inherit`
Use the `inherit` keyword to pass all the calling workflow's secrets to the called workflow. This includes all secrets the calling workflow has access to, namely organization, repository, and environment secrets. The `inherit` keyword can be used to pass secrets across repositories within the same organization, or across organizations within the same enterprise.
#### Example
{% raw %}
```yaml
on:
workflow_dispatch:
jobs:
pass-secrets-to-workflow:
uses: ./.github/workflows/called-workflow.yml
secrets: inherit
```
```yaml
on:
workflow_call:
jobs:
pass-secret-to-action:
runs-on: ubuntu-latest
steps:
- name: Use a repo or org secret from the calling workflow.
uses: echo ${{ secrets.CALLING_WORKFLOW_SECRET }}
```
{% endraw %}
{%endif%}
#### `on.workflow_call.secrets.<secret_id>`
A string identifier to associate with the secret.
@@ -745,11 +781,39 @@ If the timeout exceeds the job execution time limit for the runner, the job will
## `jobs.<job_id>.strategy`
{% data reusables.actions.jobs.section-using-a-build-matrix-for-your-jobs-strategy %}
Use `jobs.<job_id>.strategy` to use a matrix strategy for your jobs. {% data reusables.actions.jobs.about-matrix-strategy %} For more information, see "[Using a matrix for your jobs](/actions/using-jobs/using-a-matrix-for-your-jobs)."
### `jobs.<job_id>.strategy.matrix`
{% data reusables.actions.jobs.section-using-a-build-matrix-for-your-jobs-matrix %}
{% data reusables.actions.jobs.using-matrix-strategy %}
#### Example: Using a single-dimension matrix
{% data reusables.actions.jobs.single-dimension-matrix %}
#### Example: Using a multi-dimension matrix
{% data reusables.actions.jobs.multi-dimension-matrix %}
#### Example: Using contexts to create matrices
{% data reusables.actions.jobs.matrix-from-context %}
### `jobs.<job_id>.strategy.matrix.include`
{% data reusables.actions.jobs.matrix-include %}
#### Example: Expanding configurations
{% data reusables.actions.jobs.matrix-expand-with-include %}
#### Example: Adding configurations
{% data reusables.actions.jobs.matrix-add-with-include %}
### `jobs.<job_id>.strategy.matrix.exclude`
{% data reusables.actions.jobs.matrix-exclude %}
### `jobs.<job_id>.strategy.fail-fast`

View File

@@ -208,7 +208,7 @@ If this parameter is not used, the {% data variables.product.prodname_codeql_wor
{% data reusables.code-scanning.codeql-languages-bullets %}
The default {% data variables.product.prodname_codeql_workflow %} file contains a build matrix called `language` which lists the languages in your repository that are analyzed. {% data variables.product.prodname_codeql %} automatically populates this matrix when you add {% data variables.product.prodname_code_scanning %} to a repository. Using the `language` matrix optimizes {% data variables.product.prodname_codeql %} to run each analysis in parallel. We recommend that all workflows adopt this configuration due to the performance benefits of parallelizing builds. For more information about build matrices, see "[Managing complex workflows](/actions/learn-github-actions/managing-complex-workflows#using-a-build-matrix)."
The default {% data variables.product.prodname_codeql_workflow %} file contains a matrix called `language` which lists the languages in your repository that are analyzed. {% data variables.product.prodname_codeql %} automatically populates this matrix when you add {% data variables.product.prodname_code_scanning %} to a repository. Using the `language` matrix optimizes {% data variables.product.prodname_codeql %} to run each analysis in parallel. We recommend that all workflows adopt this configuration due to the performance benefits of parallelizing builds. For more information about matrices, see "[Using a matrix for your jobs](/actions/using-jobs/using-a-matrix-for-your-jobs)."
{% data reusables.code-scanning.specify-language-to-analyze %}

View File

@@ -68,7 +68,7 @@ If an automatic build of code for a compiled language within your project fails,
- Remove the `autobuild` step from your {% data variables.product.prodname_code_scanning %} workflow and add specific build steps. For information about editing the workflow, see "[Configuring {% data variables.product.prodname_code_scanning %}](/code-security/secure-coding/configuring-code-scanning#editing-a-code-scanning-workflow)." For more information about replacing the `autobuild` step, see "[Configuring the {% data variables.product.prodname_codeql %} workflow for compiled languages](/code-security/secure-coding/configuring-the-codeql-workflow-for-compiled-languages#adding-build-steps-for-a-compiled-language)."
- If your workflow doesn't explicitly specify the languages to analyze, {% data variables.product.prodname_codeql %} implicitly detects the supported languages in your code base. In this configuration, out of the compiled languages C/C++, C#, and Java, {% data variables.product.prodname_codeql %} only analyzes the language with the most source files. Edit the workflow and add a build matrix specifying the languages you want to analyze. The default CodeQL analysis workflow uses such a matrix.
- If your workflow doesn't explicitly specify the languages to analyze, {% data variables.product.prodname_codeql %} implicitly detects the supported languages in your code base. In this configuration, out of the compiled languages C/C++, C#, and Java, {% data variables.product.prodname_codeql %} only analyzes the language with the most source files. Edit the workflow and add a matrix specifying the languages you want to analyze. The default CodeQL analysis workflow uses such a matrix.
The following extracts from a workflow show how you can use a matrix within the job strategy to specify languages, and then reference each language within the "Initialize {% data variables.product.prodname_codeql %}" step:
@@ -190,7 +190,7 @@ If you use self-hosted runners to run {% data variables.product.prodname_codeql
### Use matrix builds to parallelize the analysis
The default {% data variables.product.prodname_codeql_workflow %} uses a build matrix of languages, which causes the analysis of each language to run in parallel. If you have specified the languages you want to analyze directly in the "Initialize CodeQL" step, analysis of each language will happen sequentially. To speed up analysis of multiple languages, modify your workflow to use a matrix. For more information, see the workflow extract in "[Automatic build for a compiled language fails](#automatic-build-for-a-compiled-language-fails)" above.
The default {% data variables.product.prodname_codeql_workflow %} uses a matrix of languages, which causes the analysis of each language to run in parallel. If you have specified the languages you want to analyze directly in the "Initialize CodeQL" step, analysis of each language will happen sequentially. To speed up analysis of multiple languages, modify your workflow to use a matrix. For more information, see the workflow extract in "[Automatic build for a compiled language fails](#automatic-build-for-a-compiled-language-fails)" above.
### Reduce the amount of code being analyzed in a single workflow

View File

@@ -31,8 +31,8 @@ To change how you view diffs, in the top-right corner of the diff view, click {%
![Diff option menu](/assets/images/help/desktop/diff-selection.png)
If you need to see more of the file than {% data variables.product.prodname_desktop %} shows by default, you can expand the diff.
- To see the next few lines above or below the highlighted changes, click the arrow above or below the line numbers.
If you need to see more of the file than {% data variables.product.prodname_desktop %} shows by default, you can expand the diff.
- To see the next few lines above or below the highlighted changes, click the arrow above or below the line numbers.
- To see the entire file, right-click in the diff view and click **Expand Whole File**.
![Expand diff view](/assets/images/help/desktop/expand-diff-view.png)
@@ -122,3 +122,11 @@ Once you're satisfied with the changes you've chosen to include in your commit,
![Protected branch warning](/assets/images/help/desktop/protected-branch-warning.png)
{% data reusables.desktop.push-origin %}
6. If you have a pull request based off the branch you are working on, {% data variables.product.prodname_desktop %} will display the status of the checks that have run for the pull request. For more information about checks, see "[Viewing and re-running checks in GitHub Desktop](/desktop/contributing-and-collaborating-using-github-desktop/working-with-your-remote-repository-on-github-or-github-enterprise/viewing-and-re-running-checks-in-github-desktop)."
![Checks display next to branch name](/assets/images/help/desktop/checks-dialog.png)
If a pull request has not been created for the current branch, {% data variables.product.prodname_desktop %} will give you the option to create one. For more information, see "[Creating an issue or pull request](/desktop/contributing-and-collaborating-using-github-desktop/working-with-your-remote-repository-on-github-or-github-enterprise/creating-an-issue-or-pull-request)."
![Creating a pull request](/assets/images/help/desktop/mac-create-pull-request.png)

View File

@@ -0,0 +1,62 @@
---
title: Configuring notifications in GitHub Desktop
shortTitle: Configuring notifications
intro: '{% data variables.product.prodname_desktop %} will keep you up-to-date with notifications about events that occur in your pull request branch.'
versions:
fpt: '*'
---
## About notifications in {% data variables.product.prodname_desktop %}
{% data variables.product.prodname_desktop %} will show a system notification for events that occur in the currently selected repository. Notifications will be shown when:
- Pull request checks have failed.
- A pull request review is left with a comment, approval, or requested changes.
Clicking the notification will switch application focus to {% data variables.product.prodname_desktop %} and provide more detailed information.
## Notifications about pull request check failures
When changes are made to a pull request branch, you will receive a notification if the checks fail.
![pull request checks failed notification](/assets/images/help/desktop/pull-request-checks-failed-notification.png)
Clicking the notification will display a dialog with details about the checks. Once you've reviewed why the checks have failed, you can re-run the checks, or quickly switch to the pull request branch to get started on fixing the errors. For more information, see "[Viewing and re-running checks in GitHub Desktop](/desktop/contributing-and-collaborating-using-github-desktop/working-with-your-remote-repository-on-github-or-github-enterprise/viewing-and-re-running-checks-in-github-desktop)."
![checks failed dialog](/assets/images/help/desktop/checks-failed-dialog.png)
## Notifications for pull request reviews
{% data variables.product.prodname_desktop %} will surface a system notification when a teammate has approved, commented, or requested changes in your pull request. See "[About pull request reviews](/github/collaborating-with-issues-and-pull-requests/about-pull-request-reviews)" for more information on pull request reviews.
![Pull request review notification](/assets/images/help/desktop/pull-request-review-notification.png)
Clicking the notification will switch application focus to {% data variables.product.prodname_desktop %} and provide more context for the pull request review comment.
![pull request review dialog](/assets/images/help/desktop/pull-request-review-dialog.png)
## Enabling notifications
If system notifications are disabled for {% data variables.product.prodname_desktop %} you can follow the steps below to enable them.
{% mac %}
1. Click the **Apple** menu, then select **System Preferences**.
2. Select **Notifications & Focus**.
3. Select **{% data variables.product.prodname_desktop %}** from the list of applications.
4. Click **Allow Notifications**.
![macOS Notifications & Focus](/assets/images/help/desktop/mac-enable-notifications.png)
For more information about macOS system notifications, see "[Use notifications on your Mac](https://support.apple.com/en-us/HT204079)."
{% endmac %}
{% windows %}
1. Open the **Start** menu, then select **Settings**.
2. Select **System**, then click **Notifications**.
3. Find **{% data variables.product.prodname_desktop %}** in the application list and click **On**.
![Enable Windows Notifications](/assets/images/help/desktop/windows-enable-notifications.png)
For more information about Windows system notifications, see "[Change notification settings in Windows](https://support.microsoft.com/en-us/windows/change-notification-settings-in-windows-8942c744-6198-fe56-4639-34320cf9444e)."
{% endwindows %}

View File

@@ -8,6 +8,8 @@ versions:
children:
- /creating-an-issue-or-pull-request
- /viewing-a-pull-request-in-github-desktop
- /viewing-and-re-running-checks-in-github-desktop
- /configuring-notifications-in-github-desktop
- /changing-a-remotes-url-from-github-desktop
shortTitle: Work with your remote repo
---

View File

@@ -14,6 +14,8 @@ You can view pull requests that you or your collaborators have proposed in {% da
When you view a pull request in {% data variables.product.prodname_desktop %}, you can see a history of commits that contributors made. You can also see which files the commits modified, added, or deleted. From {% data variables.product.prodname_desktop %}, you can open repositories in your preferred text editor to view any changes or make additional changes. After reviewing changes in a pull request, you can give feedback on {% data variables.product.prodname_dotcom %}. For more information, see "[About pull request reviews](/github/collaborating-with-issues-and-pull-requests/about-pull-request-reviews)."
If checks have been enabled in your repository, {% data variables.product.prodname_desktop %} will show the status of the checks on the pull request and allow you to re-run checks. For more information, see "[Viewing and re-running checks in GitHub Desktop](/desktop/contributing-and-collaborating-using-github-desktop/working-with-your-remote-repository-on-github-or-github-enterprise/viewing-and-re-running-checks-in-github-desktop)."
## Viewing a pull request in {% data variables.product.prodname_desktop %}
{% data reusables.desktop.current-branch-menu %}
{% data reusables.desktop.click-pull-requests %}

View File

@@ -0,0 +1,28 @@
---
title: Viewing and re-running checks in GitHub Desktop
shortTitle: Viewing and re-running checks
intro: 'You can view the status of checks and re-run them in {% data variables.product.prodname_desktop %}.'
versions:
fpt: '*'
---
## About checks in {% data variables.product.prodname_desktop %}
{% data variables.product.prodname_desktop %} displays the status of checks that have run in your pull request branches. The checks badge next to the branch name will display the *pending, passing,* or *failing* state of the checks. You can also re-run all, failed, or individual checks when viewing the status of the checks in {% data variables.product.prodname_desktop %}. For more information on setting up checks in your repository, see "[About status checks](/github/collaborating-with-pull-requests/collaborating-on-repositories-with-code-quality-features/about-status-checks)."
{% data variables.product.prodname_desktop %} will also show a system notification when checks fail. For more information on enabling notifications, see "[Configuring notifications in GitHub Desktop](/desktop/contributing-and-collaborating-using-github-desktop/working-with-your-remote-repository-on-github-or-github-enterprise/configuring-notifications-in-github-desktop)."
## Viewing and re-running checks
{% data reusables.desktop.current-branch-menu %}
{% data reusables.desktop.click-pull-requests %}
![Pull Requests tab in the Current Branch drop-down menu](/assets/images/help/desktop/branch-drop-down-pull-request-tab.png)
{% data reusables.desktop.choose-pr-from-list %}
![List of open pull requests in the repository](/assets/images/help/desktop/click-pull-request.png)
4. Click on the pull request number, to the right of the pull request branch name.
![Checks display next to branch name](/assets/images/help/desktop/checks-dialog.png)
5. To re-run failed checks, click **{% octicon "sync" aria-label="The sync icon" %} Re-run** and select **Re-run Failed Checks**.
![Re-run failed checks](/assets/images/help/desktop/re-run-failed-checks.png)
6. To re-run individual checks, hover over the individual check you want to re-run and select the {% octicon "sync" aria-label="The sync icon" %} icon to re-run the check.
![Re-run individual checks](/assets/images/help/desktop/re-run-individual-checks.png)
7. You will see a confirmation dialog with the summary of the checks that will be re-run. Click **Re-run Checks** to confirm that you want to perform the re-run.
![Re-run confirmation dialog](/assets/images/help/desktop/re-run-confirmation-dialog.png)

View File

@@ -300,7 +300,7 @@ versions:
- Include any additional features the setup action might provide that are useful to CI.
- If applicable, provide examples of configuring exact versions or major/minor versions.
- Include information about software already installed on GitHub-hosted runners or software configuration necessary to build and test the project.
- Provide examples of configuring build matrix strategies.
- Provide examples of configuring matrix strategies.
- Link out to any docs about available software on the GitHub-hosted runners. (Ex. https://docs.github.com/en/actions/reference/software-installed-on-github-hosted-runners).
- Include code samples.
-->

View File

@@ -0,0 +1,7 @@
# Reference: #6920
# Documentation for inheriting secrets from the calling workflow
versions:
fpt: '*'
ghec: '*'
ghes: '>= 3.6'
ghae:

View File

@@ -13,17 +13,12 @@ sections:
- When converting a user account to an organization, if the user account was an owner of the {% data variables.product.prodname_ghe_server %} enterprise account, the converted organization would incorrectly appear in the enterprise owner list.
- The `/stafftools/users/ip_addresses/:address` page responded with a `500 Internal Server Error` when attempting to display the page for an IPv6 address.
- Creating an impersonation OAuth token using the Enterprise Administration REST API resulted in an error when an integration matching the OAuth Application ID already existed.
- |
When using SAML encrypted assertions with {% data variables.product.prodname_ghe_server %} 3.4.0 and 3.4.1, a new XML attribute `WantAssertionsEncrypted` in the `SPSSODescriptor` contains an invalid attribute for SAML metadata. IdPs that consume this SAML metadata endpoint may encounter errors when validating the SAML metadata XML schema. A fix will be available in the next patch release. [Updated: 2022-04-11]
To work around this problem, you can take one of the two following actions.
- Reconfigure the IdP by uploading a static copy of the SAML metadata without the `WantAssertionsEncrypted` attribute.
- Copy the SAML metadata, remove `WantAssertionsEncrypted` attribute, host it on a web server, and reconfigure the IdP to point to that URL.
changes:
- Added support for replica domain names that are more than 63 characters.
- Configuration errors that halt a config apply run are now output to the terminal in addition to the configuration log.
- If {% data variables.product.prodname_GH_advanced_security %} features are enabled on your instance, the performance of background jobs has improved when processing batches for repository contributions.
known_issues:
- On a freshly set up {% data variables.product.prodname_ghe_server %} instance without any users, an attacker could create the first admin user.
- Custom firewall rules are removed during the upgrade process.

View File

@@ -0,0 +1 @@
A matrix strategy lets you use variables in a single job definition to automatically create multiple job runs that are based the combinations of the variables. For example, you can use a matrix strategy to test your code in multiple versions of a language or on multiple operating systems.

View File

@@ -0,0 +1,29 @@
For example, this matrix will run 10 jobs, one for each combination of `os` and `version` in the matrix, plus a job for the `os` value of `windows-latest` and `version` value of `17`.
```yaml
jobs:
example_matrix:
strategy:
matrix:
os: [macos-latest, windows-latest, ubuntu-latest]
version: [12, 14, 16]
include:
- os: windows-latest
version: 17
```
If you don't specify any matrix variables, all configurations under `include` will run. For example, the following workflow would run two jobs, one for each `include` entry. This lets you take advantage of the matrix strategy without having a fully populated matrix.
```yaml
jobs:
includes_only:
runs-on: ubuntu-latest
strategy:
matrix:
include:
- site: "production"
datacenter: "site-a"
- site: "staging"
datacenter: "site-b"
```

View File

@@ -0,0 +1,22 @@
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 %}
**Note:** All `include` combinations are processed after `exclude`. This allows you to use `include` to add back combinations that were previously excluded.
{% endnote %}

View File

@@ -0,0 +1,22 @@
For example, the following workflow will run six jobs, one for each combination of `os` and `node`. When the job for the `os` value of `windows-latest` and `node` value of `16` runs, an additional variable called `npm` with the value of `6` will be included in the job.
```yaml
jobs:
example_matrix:
strategy:
matrix:
os: [windows-latest, ubuntu-latest]
node: [12, 14, 16]
include:
- os: windows-latest
node: 16
npm: 6
runs-on: {% raw %}${{ matrix.os }}{% endraw %}
steps:
- uses: {% data reusables.actions.action-setup-node %}
with:
node-version: {% raw %}${{ matrix.node }}{% endraw %}
- if: {% raw %}${{ matrix.npm }}{% endraw %}
run: npm install -g npm@{% raw %}${{ matrix.npm }}{% endraw %}
- run: npm --version
```

View File

@@ -0,0 +1,30 @@
You can use contexts to create matrices. For more information about contexts, see "[Contexts](/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 "[Events that trigger workflows](/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 %}
```

View File

@@ -0,0 +1,38 @@
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.

View File

@@ -0,0 +1,22 @@
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-18.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 %}
```

View File

@@ -1 +1,23 @@
When `jobs.<job_id>.strategy.fail-fast` is set to `true`, {% data variables.product.prodname_dotcom %} cancels all in-progress jobs in the matrix if any `matrix` job fails. Default: `true`
You can control how job failures are handled with `jobs.<job_id>.strategy.fail-fast` and `jobs.<job_id>.continue-on-error`.
`jobs.<job_id>.strategy.fail-fast` applies to the entire matrix. If `jobs.<job_id>.strategy.fail-fast` is set to `true`, {% data variables.product.product_name %} will cancel all in-progress and queued jobs in the matrix if any job in the matrix fails. This property defaults to `true`.
`jobs.<job_id>.continue-on-error` applies to a single job. If `jobs.<job_id>.continue-on-error` is `true`, other jobs in the matrix will continue running even if the job with `jobs.<job_id>.continue-on-error: true` fails.
You can use `jobs.<job_id>.strategy.fail-fast` and `jobs.<job_id>.continue-on-error` together. For example, the following workflow will start four jobs. For each job, `continue-on-error` is determined by the value of `matrix.experimental`. If any of the jobs with `continue-on-error: false` fail, all jobs that are in progress or queued will be cancelled. If the job with `continue-on-error: true` fails, the other jobs will not be affected.
```yaml
jobs:
test:
runs-on: ubuntu-latest
continue-on-error: {% raw %}${{ matrix.experimental }}{% endraw %}
strategy:
fail-fast: true
matrix:
version: [6, 7, 8]
experimental: [false]
include:
- version: 9
experimental: true
```

View File

@@ -1,122 +0,0 @@
Use `jobs.<job_id>.strategy.matrix` to define a matrix of different job configurations. A matrix allows you to create multiple jobs by performing variable substitution in a single job definition. For example, you can use a matrix to create jobs for more than one supported version of a programming language, operating system, or tool. A matrix reuses the job's configuration and creates a job for each matrix you configure.
{% data reusables.actions.usage-matrix-limits %}
Each option you define in the `matrix` has a key and value. The keys you define become properties in the `matrix` context and you can reference the property in other areas of your workflow file. For example, if you define the key `os` that contains an array of operating systems, you can use the `matrix.os` property as the value of the `runs-on` keyword to create a job for each operating system. For more information, see "[Contexts](/actions/learn-github-actions/contexts)."
The order that you define a `matrix` matters. The first option you define will be the first job that runs in your workflow.
#### Example: Running multiple versions of Node.js
You can specify a matrix by supplying an array for the configuration options. For example, if the runner supports Node.js versions 10, 12, and 14, you could specify an array of those versions in the `matrix`.
This example creates a matrix of three jobs by setting the `node` key to an array of three Node.js versions. To use the matrix, the example sets the `matrix.node` context property as the value of the `setup-node` action's input parameter `node-version`. As a result, three jobs will run, each using a different Node.js version.
```yaml
strategy:
matrix:
node: [10, 12, 14]
steps:
# Configures the node version used on GitHub-hosted runners
- uses: {% data reusables.actions.action-setup-node %}
with:
# The Node.js version to configure
node-version: {% raw %}${{ matrix.node }}{% endraw %}
```
The `setup-node` action is the recommended way to configure a Node.js version when using {% data variables.product.prodname_dotcom %}-hosted runners. For more information, see the [`setup-node`](https://github.com/actions/setup-node) action.
#### Example: Running with multiple operating systems
You can create a matrix to run workflows on more than one runner operating system. You can also specify more than one matrix configuration. This example creates a matrix of 6 jobs:
- 2 operating systems specified in the `os` array
- 3 Node.js versions specified in the `node` array
{% data reusables.repositories.actions-matrix-builds-os %}
```yaml
runs-on: {% raw %}${{ matrix.os }}{% endraw %}
strategy:
matrix:
os: [ubuntu-18.04, ubuntu-20.04]
node: [10, 12, 14]
steps:
- uses: {% data reusables.actions.action-setup-node %}
with:
node-version: {% raw %}${{ matrix.node }}{% endraw %}
```
{% ifversion ghae %}
For more information about the configuration of self-hosted runners, see "[About self-hosted runners](/actions/hosting-your-own-runners/about-self-hosted-runners)."
{% else %}To find supported configuration options for {% data variables.product.prodname_dotcom %}-hosted runners, see "[Virtual environments for {% data variables.product.prodname_dotcom %}-hosted runners](/actions/automating-your-workflow-with-github-actions/virtual-environments-for-github-hosted-runners)."
{% endif %}
#### Example: Including additional values in combinations
You can add additional configuration options to a build matrix job that already exists. For example, if you want to use a specific version of `npm` when the job that uses `windows-latest` and version 8 of `node` runs, you can use `include` to specify that additional option.
{% raw %}
```yaml
runs-on: ${{ matrix.os }}
strategy:
matrix:
os: [macos-latest, windows-latest, ubuntu-18.04]
node: [8, 10, 12, 14]
include:
# includes a new variable of npm with a value of 6
# for the matrix leg matching the os and version
- os: windows-latest
node: 8
npm: 6
```
{% endraw %}
#### Example: Including new combinations
You can use `include` to add new jobs to a build matrix. Any unmatched include configurations are added to the matrix. For example, if you want to use `node` version 14 to build on multiple operating systems, but wanted one extra experimental job using node version 15 on Ubuntu, you can use `include` to specify that additional job.
{% raw %}
```yaml
runs-on: ${{ matrix.os }}
strategy:
matrix:
node: [14]
os: [macos-latest, windows-latest, ubuntu-18.04]
include:
- node: 15
os: ubuntu-18.04
experimental: true
```
{% endraw %}
#### Example: Excluding configurations from a matrix
You can remove a specific configurations defined in the build matrix using the `exclude` option. Using `exclude` removes a job defined by the build matrix. The number of jobs is the cross product of the number of operating systems (`os`) included in the arrays you provide, minus any subtractions (`exclude`).
{% raw %}
```yaml
runs-on: ${{ matrix.os }}
strategy:
matrix:
os: [macos-latest, windows-latest, ubuntu-18.04]
node: [8, 10, 12, 14]
exclude:
# excludes node 8 on macOS
- os: macos-latest
node: 8
```
{% endraw %}
{% note %}
**Note:** All `include` combinations are processed after `exclude`. This allows you to use `include` to add back combinations that were previously excluded.
{% endnote %}
### Using environment variables in a matrix
You can add custom environment variables for each test combination by using the `include` key. You can then refer to the custom environment variables in a later step.
{% data reusables.actions.matrix-variable-example %}

View File

@@ -1,6 +1,13 @@
Use `jobs.<job_id>.strategy.max-parallel` to set the maximum number of jobs that can run simultaneously when using a `matrix` job strategy. By default, {% data variables.product.prodname_dotcom %} will maximize the number of jobs run in parallel depending on the available runners on {% data variables.product.prodname_dotcom %}-hosted virtual machines.
By default, {% data variables.product.product_name %} 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
strategy:
max-parallel: 2
jobs:
example_matrix:
strategy:
max-parallel: 2
matrix:
version: [10, 12, 14]
os: [ubuntu-latest, windows-latest]
```

View File

@@ -1 +0,0 @@
Use `jobs.<job_id>.strategy` to create a build matrix for your jobs. You can define different variations to run each job in.

View File

@@ -0,0 +1,15 @@
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 %}
```

View File

@@ -0,0 +1,25 @@
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 veriable 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.product_name %} 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.product_name %}-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 "[Contexts](/actions/learn-github-actions/contexts)."

View File

@@ -11,3 +11,19 @@ jobs:
envPAT: ${{ secrets.envPAT }}
```
{% endraw %}
{% if actions-inherit-secrets-reusable-workflows %}
Workflows that call reusable workflows in the same organization or enterprise can use the `inherit` keyword to implicitly pass the secrets.
{% raw %}
```yaml
jobs:
call-workflow-passing-data:
uses: octo-org/example-repo/.github/workflows/reusable-workflow.yml@main
with:
username: mona
secrets: inherit
```
{% endraw %}
{%endif%}

View File

@@ -1 +0,0 @@
When you define a matrix of operating systems, you must set the value of `runs-on` to the `matrix.os` context property you defined.

View File

@@ -1,3 +1,3 @@
version https://git-lfs.github.com/spec/v1
oid sha256:af92f43836e6ee457a69cc24fce354ef9f794c612b66f20c5230555e0e19fcff
size 675448
oid sha256:cf9b6dc0c924f8338f33a86153363c19a8472998902f8565ae19369847ce0360
size 674661

View File

@@ -1,3 +1,3 @@
version https://git-lfs.github.com/spec/v1
oid sha256:90b9a68c5f82348bb9c779105c9e3eaf874a793c1dd606c884d3bc8d33356679
size 1359777
oid sha256:31820e3b8a49b9794e7e62ae4f4741adfed516d3081a21a3354a6d7afbb05017
size 1358189

View File

@@ -1,3 +1,3 @@
version https://git-lfs.github.com/spec/v1
oid sha256:3e7e89ff99efeec3f128287c4746233769f67cc51b62ea4232ea55e8e97acfc5
size 907440
oid sha256:96a12f5882dbe72a90f6b05d2348068bae6156fc1e22aa78d2b37aceda2c72a7
size 907612

View File

@@ -1,3 +1,3 @@
version https://git-lfs.github.com/spec/v1
oid sha256:fbcc422edca6a9a1cc86a7e89b6ba612c5111e7a5dbb6b1801c48611d42b7405
size 3487266
oid sha256:e428bc80429c73f63f772d70a754c12a5e07b066881f4138de201f64dff8eb39
size 3491653

View File

@@ -1,3 +1,3 @@
version https://git-lfs.github.com/spec/v1
oid sha256:f9676a2e1a6565bdb2967fe295835e565c858d0fea4a88389603660d1b142f18
size 623871
oid sha256:6bc75e2abc133cea585aab1588840de3ac233286d6b8fcb8626655d39db7a5b4
size 624580

View File

@@ -1,3 +1,3 @@
version https://git-lfs.github.com/spec/v1
oid sha256:eff23a0aa5a5da74d11c569250efbd4365e4dcea5db1e3fa919fd156620ef139
size 2626995
oid sha256:b93304c40738bd97b1b25dae510ae0bbf1215b4c911c6ceb3d2bc6026bc0ba1d
size 2627569

View File

@@ -1,3 +1,3 @@
version https://git-lfs.github.com/spec/v1
oid sha256:c99796742f8bedb8305a30b0af56d533c1a65d20afa5971e74a580a45fe4e641
size 686879
oid sha256:1a7f91bbe6b56a8755e26143bf03329181b216f13182cd647c90b74b051e376a
size 685800

View File

@@ -1,3 +1,3 @@
version https://git-lfs.github.com/spec/v1
oid sha256:902dcd6c1bb75d4e550f3e9fa7eb4f3bf36147bfb037c9d57ede99f250eec4bc
size 3667899
oid sha256:c872faac2991ced066b6710455fd8ad07f5fcd95de7cfcccb7a32a0ea1ccf646
size 3662437

View File

@@ -1,3 +1,3 @@
version https://git-lfs.github.com/spec/v1
oid sha256:581bb47bf5fb0599311bc416787bba09ed36b9170ebe18641c31712f3b8cf183
size 616530
oid sha256:571dab563c5de05e52d19f97e5e2880257c21f0e6b559011f49d25f244450d59
size 615352

View File

@@ -1,3 +1,3 @@
version https://git-lfs.github.com/spec/v1
oid sha256:8224fcd8c8e7d09150203e74cec8c0513f1b9e84b1c2ef20091cae9c1d3bd70d
size 2530997
oid sha256:e6f4ff74c09ed27ab1d4fc43e68b60fcaae9ebe0b9c697118e431edde6321e45
size 2526220

View File

@@ -1,3 +1,3 @@
version https://git-lfs.github.com/spec/v1
oid sha256:e4e1dea6e369139477c3da2c3e3e331313e9b54bdff27dd65abdf9c55beb2851
size 691595
oid sha256:79e6df23df2209ac1707b085bb9180c3c59bd0da3756d8fbea6992989c4c956f
size 692436

View File

@@ -1,3 +1,3 @@
version https://git-lfs.github.com/spec/v1
oid sha256:95c70f90229cfebe31365d7bf60c09d74a79045ac7da4544e940faddba10f034
size 1388890
oid sha256:59a323360507d734ffe5e113e778a71d997306ef3d5152cc25bcf44e079ab408
size 1388364

View File

@@ -1,3 +1,3 @@
version https://git-lfs.github.com/spec/v1
oid sha256:d7f6243eb9a28aa0f627fbf65b354fbf91b286381e021af35de85d2a3a81f4bd
size 936239
oid sha256:46466dab2c21c7e2a9d7c0d9b23494c86cdb9488f99f0b711408f48e4df2d9ef
size 937302

View File

@@ -1,3 +1,3 @@
version https://git-lfs.github.com/spec/v1
oid sha256:eb08d18a931a15951a3ec165fe40ef5096fb9005dbf56546988a5df90dcdc38c
size 3606110
oid sha256:9b42f930131f2b4e5a3441941dc2042629470ef143938084ed4763d6f8134001
size 3611216

View File

@@ -1,3 +1,3 @@
version https://git-lfs.github.com/spec/v1
oid sha256:0e797ca1944f3334fb5a479f3a7f87e55a049b45650ce1a48c019c84d65a2e67
size 641314
oid sha256:68ea078f5d8585badfd6cb948879dabb1fe8feb17dcbf968355af759a333cf12
size 640723

View File

@@ -1,3 +1,3 @@
version https://git-lfs.github.com/spec/v1
oid sha256:3ac63b4274552fb0efc1b6ab83f3ad1948ad5b558bfcbad0084d88e2073dbad4
size 2698536
oid sha256:2f4ce65d6d0674260aa6375a8cd07b3a814e7f79f6dac5823ef402d437dea6f2
size 2700175

View File

@@ -1,3 +1,3 @@
version https://git-lfs.github.com/spec/v1
oid sha256:57874d26e83d9bc22f06c5ef84f27aad0ab5f8975b130f36b41b8fe8ec1f9ad5
size 703779
oid sha256:aac59e60eac4ce45fadbfca1ac0613d3feab06b5f80fa7ecd274e946781745f8
size 703644

View File

@@ -1,3 +1,3 @@
version https://git-lfs.github.com/spec/v1
oid sha256:f7a15e27326f0d942f6aeb5db51bc6526ac8e4fba78e93e2bf35ee37fa4ac7d8
size 3760017
oid sha256:ea0beef78f642a439cfbedd793b70b11dea7387b75c8b91dbd454923b8dd78a0
size 3762087

View File

@@ -1,3 +1,3 @@
version https://git-lfs.github.com/spec/v1
oid sha256:1ff182134a3b0d6fb3a482eaefc08dc460ecf663ecacac3be56d10d7f85316bc
size 631866
oid sha256:d93c7e7fa03167a8452be39261ff0ff18159808894ac3a117686a77a97877c9d
size 630862

View File

@@ -1,3 +1,3 @@
version https://git-lfs.github.com/spec/v1
oid sha256:ad8f2009b0f63fa3895bea661d3436fc2f0509d8b41b4239eabfafa81bd15211
size 2591735
oid sha256:be276a8594a4e65a06875cce63543fef4d8dd623fe06611a4b59b4295d6ed0d4
size 2589426

View File

@@ -1,3 +1,3 @@
version https://git-lfs.github.com/spec/v1
oid sha256:3d60e577e568dc5741a93b11d5126bab72236472be0f5fc0a3eb040fd6138429
size 715431
oid sha256:2cf56329e00af7ecd19860547b00af51a37dd8896dcf0dd91fcc61d51d6a8aba
size 715297

View File

@@ -1,3 +1,3 @@
version https://git-lfs.github.com/spec/v1
oid sha256:e20f71c896f5a04844af5987f6e93d13b894b7639e02cd3251b1ef9e60b27e55
size 1438703
oid sha256:034f023d843e2408108990ae1d885f5324b358e76eaaafafaefc7ab975f412bf
size 1438315

View File

@@ -1,3 +1,3 @@
version https://git-lfs.github.com/spec/v1
oid sha256:2f815863337e086c1892e04754ff018348ef627f474e9a18ac57e29cea173091
size 971021
oid sha256:83e5720f75f56f113c67a23e23d286e9e3d59999e3239b93139a2f96f1d855db
size 972908

View File

@@ -1,3 +1,3 @@
version https://git-lfs.github.com/spec/v1
oid sha256:63c3c28824d31adc5805286b585725baa068cf70dd9aa33ca35fedf0917a6980
size 3726133
oid sha256:0df6cf51846d279fe7a6bc3e2c80c532b79b591fe183671d7daa3cbefed67a94
size 3729509

View File

@@ -1,3 +1,3 @@
version https://git-lfs.github.com/spec/v1
oid sha256:3a397944601385fa635df85a124baa1847a0f6584624075b46098796ebec573c
size 659403
oid sha256:d9ffa919d29272047e30cf2ac791b206178828714d0f157be07930f1bd6e37a7
size 660443

View File

@@ -1,3 +1,3 @@
version https://git-lfs.github.com/spec/v1
oid sha256:8382551aea9b965e716de829efaa312d8569c09404c6001d777eb740b657d0f1
size 2786696
oid sha256:bafd586134ce0ad6313b57aee3f465b8bb3baa44fd384e24e0a90c4a68c4e308
size 2787943

View File

@@ -1,3 +1,3 @@
version https://git-lfs.github.com/spec/v1
oid sha256:337432605ed6bbe3d90f9178a3666b1fce3ff359553c46633f9626dc74c5c6c2
size 727032
oid sha256:f07953c6b918479bc793c74ce17d86bc70f331b0466e02b82dfe74cc6c2cd69e
size 726317

View File

@@ -1,3 +1,3 @@
version https://git-lfs.github.com/spec/v1
oid sha256:6901933de4ebd0db0a2604d85374d890927be9c0d2ccffe23c8c583d9b68e223
size 3884906
oid sha256:64d86e600359bfbd6426a62d9da1fa3fe7cafa15df0fdb68745875fe52982378
size 3884340

View File

@@ -1,3 +1,3 @@
version https://git-lfs.github.com/spec/v1
oid sha256:5e43516e63e81a5c0128361bf57229677d2abbbce2cef69b6f1a0bc72645fcb6
size 650629
oid sha256:de0c5255441f779d18b052f39bf693843bc84a2f3f9c4aebc17ca198d129b73e
size 651040

View File

@@ -1,3 +1,3 @@
version https://git-lfs.github.com/spec/v1
oid sha256:f7415ffe07b461d799a263a6565a7477b7cb7058ccbac02043d4e00112802aba
size 2671648
oid sha256:a4e492708a6dc845808da524252ad3ca9087e142496bcb62b1adc62151b35824
size 2671387

View File

@@ -1,3 +1,3 @@
version https://git-lfs.github.com/spec/v1
oid sha256:0a96c81085da8c32d730993f0122f7f416dba92e8bd1aad1093df46c03f1a1cd
size 715010
oid sha256:842905398b5a1391443a80bbec72506d16e3717e42f1c545a5f57d2b91b6ef20
size 715635

View File

@@ -1,3 +1,3 @@
version https://git-lfs.github.com/spec/v1
oid sha256:557b4bf69bae51e1b125a8fe630e56c8038fbaf3e280aafda27aa4b232ae4c06
size 1439404
oid sha256:b2d60b155c63d124b91ca198c3382ca7219774f80de6c16e942437abc6302160
size 1439042

View File

@@ -1,3 +1,3 @@
version https://git-lfs.github.com/spec/v1
oid sha256:4a41a95e7051ef32e820fcf00be8dd21b826376c7f8d7d36becfe0c4c940aefd
size 978140
oid sha256:0b35be98e55a668a3c234c323cf02ece353896a16f463ec58005b57484530020
size 978570

View File

@@ -1,3 +1,3 @@
version https://git-lfs.github.com/spec/v1
oid sha256:86490b480d78d4018e5f06243c080436e0726a797a31827560cf0165f654af9c
size 3746147
oid sha256:abf1ac88c750cc9d67b365acddf7f0149e917e30d2b3c19fc4e92c350c42ecc2
size 3748885

View File

@@ -1,3 +1,3 @@
version https://git-lfs.github.com/spec/v1
oid sha256:306b1c0bb6736def853dccd8b59e549e0def2961f7531139822d95b6b831dbf3
size 661436
oid sha256:9231dd97959076e67d197b0fe3e644749b26d6ff14f416f1b6345f084b3aca15
size 661787

View File

@@ -1,3 +1,3 @@
version https://git-lfs.github.com/spec/v1
oid sha256:d3188da93de67cb364873938ca05f37d757da987b6f51de0bee761b85c4165f3
size 2791677
oid sha256:8d8b68acfba00e6072412a6efa90955fc7561723eea193b159b303c15ec26275
size 2791634

View File

@@ -1,3 +1,3 @@
version https://git-lfs.github.com/spec/v1
oid sha256:5cc282cc0cc8ac919c0c303c1312886d5ccfa2a6749c9eadf0a7eccb0547b7af
size 728194
oid sha256:a578e25c39bb6a1b39292f75d62e813adb4f5a2993a6f5452d51dc978e959392
size 728579

View File

@@ -1,3 +1,3 @@
version https://git-lfs.github.com/spec/v1
oid sha256:25f9feaaa8ec9560f9514c0c5466fdd9631bf22ee63aa0ba9f9ec8d36431d047
size 3891769
oid sha256:e5a73397fc411d1760f3040a958746a64d6083be128347afa10d3337d17e478c
size 3891762

View File

@@ -1,3 +1,3 @@
version https://git-lfs.github.com/spec/v1
oid sha256:41f664c30b2d7567093fb9433854fe41e9fd07e5983579ef7dbfd78fd75b4625
size 652772
oid sha256:32aec296f2703d158874fb2594efb619ebdf5ab8c477e74092ffb0ffb637da58
size 652030

View File

@@ -1,3 +1,3 @@
version https://git-lfs.github.com/spec/v1
oid sha256:c44f435e039a550dc60daeb6d23ae5b74bf420318e25bc5e5e8576893bfbf205
size 2678090
oid sha256:d0fd78cdfa68eef49ab0680882140e59fce7bfd3bafcc284dd164cc4effdd036
size 2675110

View File

@@ -1,3 +1,3 @@
version https://git-lfs.github.com/spec/v1
oid sha256:6e7af6acd7531b9ed1a0174141a405027c89a9a019516f85b1300640e8db87ff
size 910938
oid sha256:59368887e71b51d528194031856006dcac6555fe6cc89fa7d5f92e99af8b2d50
size 913282

View File

@@ -1,3 +1,3 @@
version https://git-lfs.github.com/spec/v1
oid sha256:eae8ba43589036938ef7ac5fc30addbd3d558ab3a3d889692c701b1a90a3e631
size 1485198
oid sha256:6ebd1db70157d67b58d038228017723d231124507a0edefba7281dbf69e9d4a5
size 1492476

View File

@@ -1,3 +1,3 @@
version https://git-lfs.github.com/spec/v1
oid sha256:dcb643181bcfb30815ec82d5041ddaecce13fe676a19d31c158ed94ae3115c3e
size 1233215
oid sha256:d35233a4dcc1dbaf2acdffbca2fac27839e4a1e13ad096a76647305169613ed9
size 1234871

View File

@@ -1,3 +1,3 @@
version https://git-lfs.github.com/spec/v1
oid sha256:56418e6afd0023baa4ded0c5e99a8575d5b2b78ccc4af54220cc112ec460a72d
size 4450675
oid sha256:65cb7f373042424b3b2db81b6b1fde56d20933b0d3e4017e6fe40e993e2190e6
size 4459494

View File

@@ -1,3 +1,3 @@
version https://git-lfs.github.com/spec/v1
oid sha256:dcc58f9e7dce521a3ccf0365f01d434e0fc5cb52101da40bc2c551ae2b324799
size 820991
oid sha256:ddede278a48e883aee4aa980b187c1973d34ace6f898062e5d84c787ee199060
size 823739

View File

@@ -1,3 +1,3 @@
version https://git-lfs.github.com/spec/v1
oid sha256:bf49fd0575ce34af363a954cd1c24fc71a3659c64728bfcaec799d5e95b60adc
size 3282584
oid sha256:92aaeafd731b7b355b0f4a758e13ee433c7b25fa7bb7629ed54dd2d71c68c80b
size 3296697

View File

@@ -1,3 +1,3 @@
version https://git-lfs.github.com/spec/v1
oid sha256:97628d13d596dc6cf0b36900857be592022d31e1823ceb14cbeed857ab34c999
size 921467
oid sha256:f9dd91d96c0a560e5411bf6c861a828d6edf7e7f27db207a8cd3eea1529b4377
size 922869

View File

@@ -1,3 +1,3 @@
version https://git-lfs.github.com/spec/v1
oid sha256:cd83964a9335e85356e502b5ac5c844ef6f139a985b59e56eff62d96b44f409f
size 4690635
oid sha256:8f11c5dbf6eed9a84e4c54674ef55ba2d5495ee94271e22a10e3a6b2b0dc15f2
size 4704369

View File

@@ -1,3 +1,3 @@
version https://git-lfs.github.com/spec/v1
oid sha256:41c47f9d68e79927e5d3cdeae121c616c367d0f923fa682d7b15c426777b2bc8
size 811881
oid sha256:c47dc47a2ef21e31d0972b0b7f437b1dd84a2215a7fcfecbec771e7fddb99c99
size 811703

Some files were not shown because too many files have changed in this diff Show More