Merge branch 'main' into packages-azure-storage-note
@@ -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 }}
|
||||
|
||||
2
.github/workflows/openapi-decorate.yml
vendored
@@ -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'
|
||||
|
||||
|
Before Width: | Height: | Size: 60 KiB After Width: | Height: | Size: 65 KiB |
BIN
assets/images/help/desktop/checks-dialog.png
Normal file
|
After Width: | Height: | Size: 32 KiB |
BIN
assets/images/help/desktop/checks-failed-dialog.png
Normal file
|
After Width: | Height: | Size: 86 KiB |
|
Before Width: | Height: | Size: 53 KiB After Width: | Height: | Size: 96 KiB |
BIN
assets/images/help/desktop/mac-enable-notifications.png
Normal file
|
After Width: | Height: | Size: 83 KiB |
|
After Width: | Height: | Size: 16 KiB |
BIN
assets/images/help/desktop/pull-request-list-sync.png.png
Normal file
|
After Width: | Height: | Size: 122 KiB |
BIN
assets/images/help/desktop/pull-request-review-dialog.png
Normal file
|
After Width: | Height: | Size: 42 KiB |
BIN
assets/images/help/desktop/pull-request-review-notification.png
Normal file
|
After Width: | Height: | Size: 9.7 KiB |
BIN
assets/images/help/desktop/re-run-confirmation-dialog.png
Normal file
|
After Width: | Height: | Size: 66 KiB |
BIN
assets/images/help/desktop/re-run-failed-checks.png
Normal file
|
After Width: | Height: | Size: 103 KiB |
BIN
assets/images/help/desktop/re-run-individual-checks.png
Normal file
|
After Width: | Height: | Size: 105 KiB |
BIN
assets/images/help/desktop/windows-enable-notifications.png
Normal file
|
After Width: | Height: | Size: 64 KiB |
@@ -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 %}
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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
|
||||
|
||||
|
||||
@@ -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 %} |
|
||||
| ------------- | ------------- |
|
||||
|
||||
@@ -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:
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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 %}
|
||||
60
content/actions/using-jobs/using-a-matrix-for-your-jobs.md
Normal 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 %}
|
||||
@@ -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
|
||||
|
||||
@@ -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)
|
||||
|
||||
@@ -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`
|
||||
|
||||
|
||||
@@ -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 %}
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
|
||||
@@ -31,8 +31,8 @@ To change how you view diffs, in the top-right corner of the diff view, click {%
|
||||
|
||||

|
||||
|
||||
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**.
|
||||
|
||||

|
||||
@@ -122,3 +122,11 @@ Once you're satisfied with the changes you've chosen to include in your commit,
|
||||
|
||||

|
||||
{% 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)."
|
||||
|
||||

|
||||
|
||||
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)."
|
||||
|
||||

|
||||
|
||||
@@ -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.
|
||||
|
||||

|
||||
|
||||
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)."
|
||||
|
||||

|
||||
## 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.
|
||||
|
||||

|
||||
|
||||
Clicking the notification will switch application focus to {% data variables.product.prodname_desktop %} and provide more context for the pull request review comment.
|
||||
|
||||

|
||||
## 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**.
|
||||
|
||||

|
||||
|
||||
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**.
|
||||
|
||||

|
||||
|
||||
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 %}
|
||||
@@ -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
|
||||
---
|
||||
|
||||
@@ -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 %}
|
||||
|
||||
@@ -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 %}
|
||||

|
||||
{% data reusables.desktop.choose-pr-from-list %}
|
||||

|
||||
4. Click on the pull request number, to the right of the pull request branch name.
|
||||

|
||||
5. To re-run failed checks, click **{% octicon "sync" aria-label="The sync icon" %} Re-run** and select **Re-run Failed Checks**.
|
||||

|
||||
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.
|
||||

|
||||
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.
|
||||

|
||||
@@ -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.
|
||||
-->
|
||||
|
||||
@@ -0,0 +1,7 @@
|
||||
# Reference: #6920
|
||||
# Documentation for inheriting secrets from the calling workflow
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghec: '*'
|
||||
ghes: '>= 3.6'
|
||||
ghae:
|
||||
@@ -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.
|
||||
|
||||
1
data/reusables/actions/jobs/about-matrix-strategy.md
Normal 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.
|
||||
29
data/reusables/actions/jobs/matrix-add-with-include.md
Normal 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"
|
||||
|
||||
```
|
||||
22
data/reusables/actions/jobs/matrix-exclude.md
Normal 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 %}
|
||||
22
data/reusables/actions/jobs/matrix-expand-with-include.md
Normal 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
|
||||
```
|
||||
30
data/reusables/actions/jobs/matrix-from-context.md
Normal 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 %}
|
||||
```
|
||||
38
data/reusables/actions/jobs/matrix-include.md
Normal 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.
|
||||
22
data/reusables/actions/jobs/multi-dimension-matrix.md
Normal 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 %}
|
||||
```
|
||||
@@ -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
|
||||
```
|
||||
|
||||
@@ -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 %}
|
||||
@@ -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]
|
||||
```
|
||||
|
||||
@@ -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.
|
||||
15
data/reusables/actions/jobs/single-dimension-matrix.md
Normal 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 %}
|
||||
```
|
||||
25
data/reusables/actions/jobs/using-matrix-strategy.md
Normal 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)."
|
||||
@@ -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%}
|
||||
@@ -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.
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:af92f43836e6ee457a69cc24fce354ef9f794c612b66f20c5230555e0e19fcff
|
||||
size 675448
|
||||
oid sha256:cf9b6dc0c924f8338f33a86153363c19a8472998902f8565ae19369847ce0360
|
||||
size 674661
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:90b9a68c5f82348bb9c779105c9e3eaf874a793c1dd606c884d3bc8d33356679
|
||||
size 1359777
|
||||
oid sha256:31820e3b8a49b9794e7e62ae4f4741adfed516d3081a21a3354a6d7afbb05017
|
||||
size 1358189
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:3e7e89ff99efeec3f128287c4746233769f67cc51b62ea4232ea55e8e97acfc5
|
||||
size 907440
|
||||
oid sha256:96a12f5882dbe72a90f6b05d2348068bae6156fc1e22aa78d2b37aceda2c72a7
|
||||
size 907612
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:fbcc422edca6a9a1cc86a7e89b6ba612c5111e7a5dbb6b1801c48611d42b7405
|
||||
size 3487266
|
||||
oid sha256:e428bc80429c73f63f772d70a754c12a5e07b066881f4138de201f64dff8eb39
|
||||
size 3491653
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:f9676a2e1a6565bdb2967fe295835e565c858d0fea4a88389603660d1b142f18
|
||||
size 623871
|
||||
oid sha256:6bc75e2abc133cea585aab1588840de3ac233286d6b8fcb8626655d39db7a5b4
|
||||
size 624580
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:eff23a0aa5a5da74d11c569250efbd4365e4dcea5db1e3fa919fd156620ef139
|
||||
size 2626995
|
||||
oid sha256:b93304c40738bd97b1b25dae510ae0bbf1215b4c911c6ceb3d2bc6026bc0ba1d
|
||||
size 2627569
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:c99796742f8bedb8305a30b0af56d533c1a65d20afa5971e74a580a45fe4e641
|
||||
size 686879
|
||||
oid sha256:1a7f91bbe6b56a8755e26143bf03329181b216f13182cd647c90b74b051e376a
|
||||
size 685800
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:902dcd6c1bb75d4e550f3e9fa7eb4f3bf36147bfb037c9d57ede99f250eec4bc
|
||||
size 3667899
|
||||
oid sha256:c872faac2991ced066b6710455fd8ad07f5fcd95de7cfcccb7a32a0ea1ccf646
|
||||
size 3662437
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:581bb47bf5fb0599311bc416787bba09ed36b9170ebe18641c31712f3b8cf183
|
||||
size 616530
|
||||
oid sha256:571dab563c5de05e52d19f97e5e2880257c21f0e6b559011f49d25f244450d59
|
||||
size 615352
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:8224fcd8c8e7d09150203e74cec8c0513f1b9e84b1c2ef20091cae9c1d3bd70d
|
||||
size 2530997
|
||||
oid sha256:e6f4ff74c09ed27ab1d4fc43e68b60fcaae9ebe0b9c697118e431edde6321e45
|
||||
size 2526220
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:e4e1dea6e369139477c3da2c3e3e331313e9b54bdff27dd65abdf9c55beb2851
|
||||
size 691595
|
||||
oid sha256:79e6df23df2209ac1707b085bb9180c3c59bd0da3756d8fbea6992989c4c956f
|
||||
size 692436
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:95c70f90229cfebe31365d7bf60c09d74a79045ac7da4544e940faddba10f034
|
||||
size 1388890
|
||||
oid sha256:59a323360507d734ffe5e113e778a71d997306ef3d5152cc25bcf44e079ab408
|
||||
size 1388364
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:d7f6243eb9a28aa0f627fbf65b354fbf91b286381e021af35de85d2a3a81f4bd
|
||||
size 936239
|
||||
oid sha256:46466dab2c21c7e2a9d7c0d9b23494c86cdb9488f99f0b711408f48e4df2d9ef
|
||||
size 937302
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:eb08d18a931a15951a3ec165fe40ef5096fb9005dbf56546988a5df90dcdc38c
|
||||
size 3606110
|
||||
oid sha256:9b42f930131f2b4e5a3441941dc2042629470ef143938084ed4763d6f8134001
|
||||
size 3611216
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:0e797ca1944f3334fb5a479f3a7f87e55a049b45650ce1a48c019c84d65a2e67
|
||||
size 641314
|
||||
oid sha256:68ea078f5d8585badfd6cb948879dabb1fe8feb17dcbf968355af759a333cf12
|
||||
size 640723
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:3ac63b4274552fb0efc1b6ab83f3ad1948ad5b558bfcbad0084d88e2073dbad4
|
||||
size 2698536
|
||||
oid sha256:2f4ce65d6d0674260aa6375a8cd07b3a814e7f79f6dac5823ef402d437dea6f2
|
||||
size 2700175
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:57874d26e83d9bc22f06c5ef84f27aad0ab5f8975b130f36b41b8fe8ec1f9ad5
|
||||
size 703779
|
||||
oid sha256:aac59e60eac4ce45fadbfca1ac0613d3feab06b5f80fa7ecd274e946781745f8
|
||||
size 703644
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:f7a15e27326f0d942f6aeb5db51bc6526ac8e4fba78e93e2bf35ee37fa4ac7d8
|
||||
size 3760017
|
||||
oid sha256:ea0beef78f642a439cfbedd793b70b11dea7387b75c8b91dbd454923b8dd78a0
|
||||
size 3762087
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:1ff182134a3b0d6fb3a482eaefc08dc460ecf663ecacac3be56d10d7f85316bc
|
||||
size 631866
|
||||
oid sha256:d93c7e7fa03167a8452be39261ff0ff18159808894ac3a117686a77a97877c9d
|
||||
size 630862
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:ad8f2009b0f63fa3895bea661d3436fc2f0509d8b41b4239eabfafa81bd15211
|
||||
size 2591735
|
||||
oid sha256:be276a8594a4e65a06875cce63543fef4d8dd623fe06611a4b59b4295d6ed0d4
|
||||
size 2589426
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:3d60e577e568dc5741a93b11d5126bab72236472be0f5fc0a3eb040fd6138429
|
||||
size 715431
|
||||
oid sha256:2cf56329e00af7ecd19860547b00af51a37dd8896dcf0dd91fcc61d51d6a8aba
|
||||
size 715297
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:e20f71c896f5a04844af5987f6e93d13b894b7639e02cd3251b1ef9e60b27e55
|
||||
size 1438703
|
||||
oid sha256:034f023d843e2408108990ae1d885f5324b358e76eaaafafaefc7ab975f412bf
|
||||
size 1438315
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:2f815863337e086c1892e04754ff018348ef627f474e9a18ac57e29cea173091
|
||||
size 971021
|
||||
oid sha256:83e5720f75f56f113c67a23e23d286e9e3d59999e3239b93139a2f96f1d855db
|
||||
size 972908
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:63c3c28824d31adc5805286b585725baa068cf70dd9aa33ca35fedf0917a6980
|
||||
size 3726133
|
||||
oid sha256:0df6cf51846d279fe7a6bc3e2c80c532b79b591fe183671d7daa3cbefed67a94
|
||||
size 3729509
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:3a397944601385fa635df85a124baa1847a0f6584624075b46098796ebec573c
|
||||
size 659403
|
||||
oid sha256:d9ffa919d29272047e30cf2ac791b206178828714d0f157be07930f1bd6e37a7
|
||||
size 660443
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:8382551aea9b965e716de829efaa312d8569c09404c6001d777eb740b657d0f1
|
||||
size 2786696
|
||||
oid sha256:bafd586134ce0ad6313b57aee3f465b8bb3baa44fd384e24e0a90c4a68c4e308
|
||||
size 2787943
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:337432605ed6bbe3d90f9178a3666b1fce3ff359553c46633f9626dc74c5c6c2
|
||||
size 727032
|
||||
oid sha256:f07953c6b918479bc793c74ce17d86bc70f331b0466e02b82dfe74cc6c2cd69e
|
||||
size 726317
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:6901933de4ebd0db0a2604d85374d890927be9c0d2ccffe23c8c583d9b68e223
|
||||
size 3884906
|
||||
oid sha256:64d86e600359bfbd6426a62d9da1fa3fe7cafa15df0fdb68745875fe52982378
|
||||
size 3884340
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:5e43516e63e81a5c0128361bf57229677d2abbbce2cef69b6f1a0bc72645fcb6
|
||||
size 650629
|
||||
oid sha256:de0c5255441f779d18b052f39bf693843bc84a2f3f9c4aebc17ca198d129b73e
|
||||
size 651040
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:f7415ffe07b461d799a263a6565a7477b7cb7058ccbac02043d4e00112802aba
|
||||
size 2671648
|
||||
oid sha256:a4e492708a6dc845808da524252ad3ca9087e142496bcb62b1adc62151b35824
|
||||
size 2671387
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:0a96c81085da8c32d730993f0122f7f416dba92e8bd1aad1093df46c03f1a1cd
|
||||
size 715010
|
||||
oid sha256:842905398b5a1391443a80bbec72506d16e3717e42f1c545a5f57d2b91b6ef20
|
||||
size 715635
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:557b4bf69bae51e1b125a8fe630e56c8038fbaf3e280aafda27aa4b232ae4c06
|
||||
size 1439404
|
||||
oid sha256:b2d60b155c63d124b91ca198c3382ca7219774f80de6c16e942437abc6302160
|
||||
size 1439042
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:4a41a95e7051ef32e820fcf00be8dd21b826376c7f8d7d36becfe0c4c940aefd
|
||||
size 978140
|
||||
oid sha256:0b35be98e55a668a3c234c323cf02ece353896a16f463ec58005b57484530020
|
||||
size 978570
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:86490b480d78d4018e5f06243c080436e0726a797a31827560cf0165f654af9c
|
||||
size 3746147
|
||||
oid sha256:abf1ac88c750cc9d67b365acddf7f0149e917e30d2b3c19fc4e92c350c42ecc2
|
||||
size 3748885
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:306b1c0bb6736def853dccd8b59e549e0def2961f7531139822d95b6b831dbf3
|
||||
size 661436
|
||||
oid sha256:9231dd97959076e67d197b0fe3e644749b26d6ff14f416f1b6345f084b3aca15
|
||||
size 661787
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:d3188da93de67cb364873938ca05f37d757da987b6f51de0bee761b85c4165f3
|
||||
size 2791677
|
||||
oid sha256:8d8b68acfba00e6072412a6efa90955fc7561723eea193b159b303c15ec26275
|
||||
size 2791634
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:5cc282cc0cc8ac919c0c303c1312886d5ccfa2a6749c9eadf0a7eccb0547b7af
|
||||
size 728194
|
||||
oid sha256:a578e25c39bb6a1b39292f75d62e813adb4f5a2993a6f5452d51dc978e959392
|
||||
size 728579
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:25f9feaaa8ec9560f9514c0c5466fdd9631bf22ee63aa0ba9f9ec8d36431d047
|
||||
size 3891769
|
||||
oid sha256:e5a73397fc411d1760f3040a958746a64d6083be128347afa10d3337d17e478c
|
||||
size 3891762
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:41f664c30b2d7567093fb9433854fe41e9fd07e5983579ef7dbfd78fd75b4625
|
||||
size 652772
|
||||
oid sha256:32aec296f2703d158874fb2594efb619ebdf5ab8c477e74092ffb0ffb637da58
|
||||
size 652030
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:c44f435e039a550dc60daeb6d23ae5b74bf420318e25bc5e5e8576893bfbf205
|
||||
size 2678090
|
||||
oid sha256:d0fd78cdfa68eef49ab0680882140e59fce7bfd3bafcc284dd164cc4effdd036
|
||||
size 2675110
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:6e7af6acd7531b9ed1a0174141a405027c89a9a019516f85b1300640e8db87ff
|
||||
size 910938
|
||||
oid sha256:59368887e71b51d528194031856006dcac6555fe6cc89fa7d5f92e99af8b2d50
|
||||
size 913282
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:eae8ba43589036938ef7ac5fc30addbd3d558ab3a3d889692c701b1a90a3e631
|
||||
size 1485198
|
||||
oid sha256:6ebd1db70157d67b58d038228017723d231124507a0edefba7281dbf69e9d4a5
|
||||
size 1492476
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:dcb643181bcfb30815ec82d5041ddaecce13fe676a19d31c158ed94ae3115c3e
|
||||
size 1233215
|
||||
oid sha256:d35233a4dcc1dbaf2acdffbca2fac27839e4a1e13ad096a76647305169613ed9
|
||||
size 1234871
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:56418e6afd0023baa4ded0c5e99a8575d5b2b78ccc4af54220cc112ec460a72d
|
||||
size 4450675
|
||||
oid sha256:65cb7f373042424b3b2db81b6b1fde56d20933b0d3e4017e6fe40e993e2190e6
|
||||
size 4459494
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:dcc58f9e7dce521a3ccf0365f01d434e0fc5cb52101da40bc2c551ae2b324799
|
||||
size 820991
|
||||
oid sha256:ddede278a48e883aee4aa980b187c1973d34ace6f898062e5d84c787ee199060
|
||||
size 823739
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:bf49fd0575ce34af363a954cd1c24fc71a3659c64728bfcaec799d5e95b60adc
|
||||
size 3282584
|
||||
oid sha256:92aaeafd731b7b355b0f4a758e13ee433c7b25fa7bb7629ed54dd2d71c68c80b
|
||||
size 3296697
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:97628d13d596dc6cf0b36900857be592022d31e1823ceb14cbeed857ab34c999
|
||||
size 921467
|
||||
oid sha256:f9dd91d96c0a560e5411bf6c861a828d6edf7e7f27db207a8cd3eea1529b4377
|
||||
size 922869
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:cd83964a9335e85356e502b5ac5c844ef6f139a985b59e56eff62d96b44f409f
|
||||
size 4690635
|
||||
oid sha256:8f11c5dbf6eed9a84e4c54674ef55ba2d5495ee94271e22a10e3a6b2b0dc15f2
|
||||
size 4704369
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:41c47f9d68e79927e5d3cdeae121c616c367d0f923fa682d7b15c426777b2bc8
|
||||
size 811881
|
||||
oid sha256:c47dc47a2ef21e31d0972b0b7f437b1dd84a2215a7fcfecbec771e7fddb99c99
|
||||
size 811703
|
||||
|
||||