updating content files
This commit is contained in:
Grace Park
@@ -17,23 +17,23 @@ versions:
|
||||
{% data reusables.actions.enterprise-github-hosted-runners %}
|
||||
{% data reusables.actions.ae-beta %}
|
||||
|
||||
### About YAML syntax for workflows
|
||||
## About YAML syntax for workflows
|
||||
|
||||
Workflow files use YAML syntax, and must have either a `.yml` or `.yaml` file extension. {% data reusables.actions.learn-more-about-yaml %}
|
||||
|
||||
You must store workflow files in the `.github/workflows` directory of your repository.
|
||||
|
||||
### `name`
|
||||
## `name`
|
||||
|
||||
The name of your workflow. {% data variables.product.prodname_dotcom %} displays the names of your workflows on your repository's actions page. If you omit `name`, {% data variables.product.prodname_dotcom %} sets it to the workflow file path relative to the root of the repository.
|
||||
|
||||
### `on`
|
||||
## `on`
|
||||
|
||||
**Required**. The name of the {% data variables.product.prodname_dotcom %} event that triggers the workflow. You can provide a single event `string`, `array` of events, `array` of event `types`, or an event configuration `map` that schedules a workflow or restricts the execution of a workflow to specific files, tags, or branch changes. For a list of available events, see "[Events that trigger workflows](/articles/events-that-trigger-workflows)."
|
||||
|
||||
{% data reusables.github-actions.actions-on-examples %}
|
||||
|
||||
### `on.<event_name>.types`
|
||||
## `on.<event_name>.types`
|
||||
|
||||
Selects the types of activity that will trigger a workflow run. Most GitHub events are triggered by more than one type of activity. For example, the event for the release resource is triggered when a release is `published`, `unpublished`, `created`, `edited`, `deleted`, or `prereleased`. The `types` keyword enables you to narrow down activity that causes the workflow to run. When only one activity type triggers a webhook event, the `types` keyword is unnecessary.
|
||||
|
||||
@@ -47,13 +47,13 @@ on:
|
||||
types: [published, created, edited]
|
||||
```
|
||||
|
||||
### `on.<push|pull_request>.<branches|tags>`
|
||||
## `on.<push|pull_request>.<branches|tags>`
|
||||
|
||||
When using the `push` and `pull_request` events, you can configure a workflow to run on specific branches or tags. For a `pull_request` event, only branches and tags on the base are evaluated. If you define only `tags` or only `branches`, the workflow won't run for events affecting the undefined Git ref.
|
||||
|
||||
The `branches`, `branches-ignore`, `tags`, and `tags-ignore` keywords accept glob patterns that use the `*` and `**` wildcard characters to match more than one branch or tag name. For more information, see the "[Filter pattern cheat sheet](#filter-pattern-cheat-sheet)."
|
||||
|
||||
#### Example: Including branches and tags
|
||||
### Example: Including branches and tags
|
||||
|
||||
The patterns defined in `branches` and `tags` are evaluated against the Git ref's name. For example, defining the pattern `mona/octocat` in `branches` will match the `refs/heads/mona/octocat` Git ref. The pattern `releases/**` will match the `refs/heads/releases/10` Git ref.
|
||||
|
||||
@@ -74,7 +74,7 @@ on:
|
||||
- v1.* # Push events to v1.0, v1.1, and v1.9 tags
|
||||
```
|
||||
|
||||
#### Example: Ignoring branches and tags
|
||||
### Example: Ignoring branches and tags
|
||||
|
||||
Anytime a pattern matches the `branches-ignore` or `tags-ignore` pattern, the workflow will not run. The patterns defined in `branches-ignore` and `tags-ignore` are evaluated against the Git ref's name. For example, defining the pattern `mona/octocat` in `branches` will match the `refs/heads/mona/octocat` Git ref. The pattern `releases/**-alpha` in `branches` will match the `refs/releases/beta/3-alpha` Git ref.
|
||||
|
||||
@@ -92,13 +92,13 @@ on:
|
||||
- v1.* # Push events to tags v1.0, v1.1, and v1.9
|
||||
```
|
||||
|
||||
#### Excluding branches and tags
|
||||
### Excluding branches and tags
|
||||
|
||||
You can use two types of filters to prevent a workflow from running on pushes and pull requests to tags and branches.
|
||||
- `branches` or `branches-ignore` - You cannot use both the `branches` and `branches-ignore` filters for the same event in a workflow. Use the `branches` filter when you need to filter branches for positive matches and exclude branches. Use the `branches-ignore` filter when you only need to exclude branch names.
|
||||
- `tags` or `tags-ignore` - You cannot use both the `tags` and `tags-ignore` filters for the same event in a workflow. Use the `tags` filter when you need to filter tags for positive matches and exclude tags. Use the `tags-ignore` filter when you only need to exclude tag names.
|
||||
|
||||
#### Example: Using positive and negative patterns
|
||||
### Example: Using positive and negative patterns
|
||||
|
||||
You can exclude `tags` and `branches` using the `!` character. The order that you define patterns matters.
|
||||
- A matching negative pattern (prefixed with `!`) after a positive match will exclude the Git ref.
|
||||
@@ -114,13 +114,13 @@ on:
|
||||
- '!releases/**-alpha'
|
||||
```
|
||||
|
||||
### `on.<push|pull_request>.paths`
|
||||
## `on.<push|pull_request>.paths`
|
||||
|
||||
When using the `push` and `pull_request` events, you can configure a workflow to run when at least one file does not match `paths-ignore` or at least one modified file matches the configured `paths`. Path filters are not evaluated for pushes to tags.
|
||||
|
||||
The `paths-ignore` and `paths` keywords accept glob patterns that use the `*` and `**` wildcard characters to match more than one path name. For more information, see the "[Filter pattern cheat sheet](#filter-pattern-cheat-sheet)."
|
||||
|
||||
#### Example: Ignoring paths
|
||||
### Example: Ignoring paths
|
||||
|
||||
When all the path names match patterns in `paths-ignore`, the workflow will not run. {% data variables.product.prodname_dotcom %} evaluates patterns defined in `paths-ignore` against the path name. A workflow with the following path filter will only run on `push` events that include at least one file outside the `docs` directory at the root of the repository.
|
||||
|
||||
@@ -131,7 +131,7 @@ on:
|
||||
- 'docs/**'
|
||||
```
|
||||
|
||||
#### Example: Including paths
|
||||
### Example: Including paths
|
||||
|
||||
If at least one path matches a pattern in the `paths` filter, the workflow runs. To trigger a build anytime you push a JavaScript file, you can use a wildcard pattern.
|
||||
|
||||
@@ -142,13 +142,13 @@ on:
|
||||
- '**.js'
|
||||
```
|
||||
|
||||
#### Excluding paths
|
||||
### Excluding paths
|
||||
|
||||
You can exclude paths using two types of filters. You cannot use both of these filters for the same event in a workflow.
|
||||
- `paths-ignore` - Use the `paths-ignore` filter when you only need to exclude path names.
|
||||
- `paths` - Use the `paths` filter when you need to filter paths for positive matches and exclude paths.
|
||||
|
||||
#### Example: Using positive and negative patterns
|
||||
### Example: Using positive and negative patterns
|
||||
|
||||
You can exclude `paths` using the `!` character. The order that you define patterns matters:
|
||||
- A matching negative pattern (prefixed with `!`) after a positive match will exclude the path.
|
||||
@@ -164,7 +164,7 @@ on:
|
||||
- '!sub-project/docs/**'
|
||||
```
|
||||
|
||||
#### Git diff comparisons
|
||||
### Git diff comparisons
|
||||
|
||||
{% note %}
|
||||
|
||||
@@ -181,14 +181,14 @@ The filter determines if a workflow should run by evaluating the changed files a
|
||||
|
||||
For more information, see "[About comparing branches in pull requests](/articles/about-comparing-branches-in-pull-requests)."
|
||||
|
||||
### `on.schedule`
|
||||
## `on.schedule`
|
||||
|
||||
{% data reusables.repositories.actions-scheduled-workflow-example %}
|
||||
|
||||
For more information about cron syntax, see "[Events that trigger workflows](/actions/automating-your-workflow-with-github-actions/events-that-trigger-workflows#scheduled-events)."
|
||||
|
||||
{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.1" or currentVersion == "github-ae@next" %}
|
||||
### `permissions`
|
||||
## `permissions`
|
||||
|
||||
You can modify the default permissions granted to the `GITHUB_TOKEN`, adding or removing access as required, so that you only allow the minimum required access. For more information, see "[Authentication in a workflow](/actions/reference/authentication-in-a-workflow#permissions-for-the-github_token)."
|
||||
|
||||
@@ -197,7 +197,7 @@ You can use `permissions` either as a top-level key, to apply to all jobs in the
|
||||
{% data reusables.github-actions.github-token-available-permissions %}
|
||||
{% data reusables.github-actions.forked-write-permission %}
|
||||
|
||||
#### Example
|
||||
### Example
|
||||
|
||||
This example shows permissions being set for the `GITHUB_TOKEN` that will apply to all jobs in the workflow. All permissions are granted read access.
|
||||
|
||||
@@ -213,32 +213,32 @@ jobs:
|
||||
```
|
||||
{% endif %}
|
||||
|
||||
### `env`
|
||||
## `env`
|
||||
|
||||
A `map` of environment variables that are available to the steps of all jobs in the workflow. You can also set environment variables that are only available to the steps of a single job or to a single step. For more information, see [`jobs.<job_id>.env`](#jobsjob_idenv) and [`jobs.<job_id>.steps[*].env`](#jobsjob_idstepsenv).
|
||||
|
||||
{% data reusables.repositories.actions-env-var-note %}
|
||||
|
||||
#### Example
|
||||
### Example
|
||||
|
||||
```yaml
|
||||
env:
|
||||
SERVER: production
|
||||
```
|
||||
|
||||
### `defaults`
|
||||
## `defaults`
|
||||
|
||||
A `map` of default settings that will apply to all jobs in the workflow. You can also set default settings that are only available to a job. For more information, see [`jobs.<job_id>.defaults`](#jobsjob_iddefaults).
|
||||
|
||||
{% data reusables.github-actions.defaults-override %}
|
||||
|
||||
### `defaults.run`
|
||||
## `defaults.run`
|
||||
|
||||
You can provide default `shell` and `working-directory` options for all [`run`](#jobsjob_idstepsrun) steps in a workflow. You can also set default settings for `run` that are only available to a job. For more information, see [`jobs.<job_id>.defaults.run`](#jobsjob_iddefaultsrun). You cannot use contexts or expressions in this keyword.
|
||||
|
||||
{% data reusables.github-actions.defaults-override %}
|
||||
|
||||
#### Example
|
||||
### Example
|
||||
|
||||
```yaml
|
||||
defaults:
|
||||
@@ -248,7 +248,7 @@ defaults:
|
||||
```
|
||||
|
||||
{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.0" or currentVersion == "github-ae@next" %}
|
||||
### `concurrency`
|
||||
## `concurrency`
|
||||
|
||||
{% data reusables.actions.concurrency-beta %}
|
||||
|
||||
@@ -259,7 +259,7 @@ You can also specify `concurrency` at the job level. For more information, see [
|
||||
{% data reusables.actions.actions-group-concurrency %}
|
||||
|
||||
{% endif %}
|
||||
### `jobs`
|
||||
## `jobs`
|
||||
|
||||
A workflow run is made up of one or more jobs. Jobs run in parallel by default. To run jobs sequentially, you can define dependencies on other jobs using the `jobs.<job_id>.needs` keyword.
|
||||
|
||||
@@ -269,11 +269,11 @@ You can run an unlimited number of jobs as long as you are within the workflow u
|
||||
|
||||
If you need to find the unique identifier of a job running in a workflow run, you can use the {% data variables.product.prodname_dotcom %} API. For more information, see "[Workflow Jobs](/rest/reference/actions#workflow-jobs)."
|
||||
|
||||
### `jobs.<job_id>`
|
||||
## `jobs.<job_id>`
|
||||
|
||||
Each job must have an id to associate with the job. The key `job_id` is a string and its value is a map of the job's configuration data. You must replace `<job_id>` with a string that is unique to the `jobs` object. The `<job_id>` must start with a letter or `_` and contain only alphanumeric characters, `-`, or `_`.
|
||||
|
||||
#### Example
|
||||
### Example
|
||||
|
||||
```yaml
|
||||
jobs:
|
||||
@@ -283,15 +283,15 @@ jobs:
|
||||
name: My second job
|
||||
```
|
||||
|
||||
### `jobs.<job_id>.name`
|
||||
## `jobs.<job_id>.name`
|
||||
|
||||
The name of the job displayed on {% data variables.product.prodname_dotcom %}.
|
||||
|
||||
### `jobs.<job_id>.needs`
|
||||
## `jobs.<job_id>.needs`
|
||||
|
||||
Identifies any jobs that must complete successfully before this job will run. It can be a string or array of strings. If a job fails, all jobs that need it are skipped unless the jobs use a conditional expression that causes the job to continue.
|
||||
|
||||
#### Example: Requiring dependent jobs to be successful
|
||||
### Example: Requiring dependent jobs to be successful
|
||||
|
||||
```yaml
|
||||
jobs:
|
||||
@@ -310,7 +310,7 @@ The jobs in this example run sequentially:
|
||||
2. `job2`
|
||||
3. `job3`
|
||||
|
||||
#### Example: Not requiring dependent jobs to be successful
|
||||
### Example: Not requiring dependent jobs to be successful
|
||||
|
||||
```yaml
|
||||
jobs:
|
||||
@@ -324,16 +324,16 @@ jobs:
|
||||
|
||||
In this example, `job3` uses the `always()` conditional expression so that it always runs after `job1` and `job2` have completed, regardless of whether they were successful. For more information, see "[Context and expression syntax](/actions/reference/context-and-expression-syntax-for-github-actions#job-status-check-functions)."
|
||||
|
||||
### `jobs.<job_id>.runs-on`
|
||||
## `jobs.<job_id>.runs-on`
|
||||
|
||||
**Required**. The type of machine to run the job on. The machine can be either a {% data variables.product.prodname_dotcom %}-hosted runner or a self-hosted runner.
|
||||
|
||||
{% if currentVersion == "github-ae@latest" %}
|
||||
#### {% data variables.actions.hosted_runner %}s
|
||||
### {% data variables.actions.hosted_runner %}s
|
||||
|
||||
If you use an {% data variables.actions.hosted_runner %}, each job runs in a fresh instance of a virtual environment specified by `runs-on`.
|
||||
|
||||
##### Example
|
||||
#### Example
|
||||
|
||||
```yaml
|
||||
runs-on: [AE-runner-for-CI]
|
||||
@@ -344,7 +344,7 @@ For more information, see "[About {% data variables.actions.hosted_runner %}s](/
|
||||
{% else %}
|
||||
{% data reusables.actions.enterprise-github-hosted-runners %}
|
||||
|
||||
#### {% data variables.product.prodname_dotcom %}-hosted runners
|
||||
### {% data variables.product.prodname_dotcom %}-hosted runners
|
||||
|
||||
If you use a {% data variables.product.prodname_dotcom %}-hosted runner, each job runs in a fresh instance of a virtual environment specified by `runs-on`.
|
||||
|
||||
@@ -354,7 +354,7 @@ Available {% data variables.product.prodname_dotcom %}-hosted runner types are:
|
||||
|
||||
{% data reusables.github-actions.macos-runner-preview %}
|
||||
|
||||
##### Example
|
||||
#### Example
|
||||
|
||||
```yaml
|
||||
runs-on: ubuntu-latest
|
||||
@@ -363,13 +363,13 @@ runs-on: ubuntu-latest
|
||||
For more information, see "[Virtual environments for {% data variables.product.prodname_dotcom %}-hosted runners](/github/automating-your-workflow-with-github-actions/virtual-environments-for-github-hosted-runners)."
|
||||
{% endif %}
|
||||
|
||||
#### Self-hosted runners
|
||||
### Self-hosted runners
|
||||
|
||||
{% data reusables.actions.ae-self-hosted-runners-notice %}
|
||||
|
||||
{% data reusables.github-actions.self-hosted-runner-labels-runs-on %}
|
||||
|
||||
##### Example
|
||||
#### Example
|
||||
|
||||
```yaml
|
||||
runs-on: [self-hosted, linux]
|
||||
@@ -378,7 +378,7 @@ runs-on: [self-hosted, linux]
|
||||
For more information, see "[About self-hosted runners](/github/automating-your-workflow-with-github-actions/about-self-hosted-runners)" and "[Using self-hosted runners in a workflow](/github/automating-your-workflow-with-github-actions/using-self-hosted-runners-in-a-workflow)."
|
||||
|
||||
{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.1" or currentVersion == "github-ae@next" %}
|
||||
### `jobs.<job_id>.permissions`
|
||||
## `jobs.<job_id>.permissions`
|
||||
|
||||
You can modify the default permissions granted to the `GITHUB_TOKEN`, adding or removing access as required, so that you only allow the minimum required access. For more information, see "[Authentication in a workflow](/actions/reference/authentication-in-a-workflow#permissions-for-the-github_token)."
|
||||
|
||||
@@ -387,7 +387,7 @@ By specifying the permission within a job definition, you can configure a differ
|
||||
{% data reusables.github-actions.github-token-available-permissions %}
|
||||
{% data reusables.github-actions.forked-write-permission %}
|
||||
|
||||
#### Example
|
||||
### Example
|
||||
|
||||
This example shows permissions being set for the `GITHUB_TOKEN` that will only apply to the job named `stale`. Write access is granted for the `issues` and `pull-requests` scopes. All other scopes will have no access.
|
||||
|
||||
@@ -406,20 +406,20 @@ jobs:
|
||||
{% endif %}
|
||||
|
||||
{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.0" or currentVersion == "github-ae@latest" %}
|
||||
### `jobs.<job_id>.environment`
|
||||
## `jobs.<job_id>.environment`
|
||||
|
||||
The environment that the job references. All environment protection rules must pass before a job referencing the environment is sent to a runner. For more information, see "[Environments](/actions/reference/environments)."
|
||||
|
||||
You can provide the environment as only the environment `name`, or as an environment object with the `name` and `url`. The URL maps to `environment_url` in the deployments API. For more information about the deployments API, see "[Deployments](/rest/reference/repos#deployments)."
|
||||
|
||||
##### Example using a single environment name
|
||||
#### Example using a single environment name
|
||||
{% raw %}
|
||||
```yaml
|
||||
environment: staging_environment
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
##### Example using environment name and URL
|
||||
#### Example using environment name and URL
|
||||
|
||||
```yaml
|
||||
environment:
|
||||
@@ -429,7 +429,7 @@ environment:
|
||||
|
||||
The URL can be an expression and can use any context except for the `secrets` context. For more information about expressions, see "[Context and expression syntax for {% data variables.product.prodname_actions %}](/actions/reference/context-and-expression-syntax-for-github-actions)."
|
||||
|
||||
#### Example
|
||||
### Example
|
||||
{% raw %}
|
||||
```yaml
|
||||
environment:
|
||||
@@ -441,7 +441,7 @@ environment:
|
||||
|
||||
|
||||
{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.0" or currentVersion == "github-ae@next" %}
|
||||
### `jobs.<job_id>.concurrency`
|
||||
## `jobs.<job_id>.concurrency`
|
||||
|
||||
{% data reusables.actions.concurrency-beta %}
|
||||
|
||||
@@ -458,7 +458,7 @@ You can also specify `concurrency` at the workflow level. For more information,
|
||||
{% data reusables.actions.actions-group-concurrency %}
|
||||
|
||||
{% endif %}
|
||||
### `jobs.<job_id>.outputs`
|
||||
## `jobs.<job_id>.outputs`
|
||||
|
||||
A `map` of outputs for a job. Job outputs are available to all downstream jobs that depend on this job. For more information on defining job dependencies, see [`jobs.<job_id>.needs`](#jobsjob_idneeds).
|
||||
|
||||
@@ -466,7 +466,7 @@ Job outputs are strings, and job outputs containing expressions are evaluated on
|
||||
|
||||
To use job outputs in a dependent job, you can use the `needs` context. For more information, see "[Context and expression syntax for {% data variables.product.prodname_actions %}](/actions/reference/context-and-expression-syntax-for-github-actions#needs-context)."
|
||||
|
||||
#### Example
|
||||
### Example
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
@@ -490,13 +490,13 @@ jobs:
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
### `jobs.<job_id>.env`
|
||||
## `jobs.<job_id>.env`
|
||||
|
||||
A `map` of environment variables that are available to all steps in the job. You can also set environment variables for the entire workflow or an individual step. For more information, see [`env`](#env) and [`jobs.<job_id>.steps[*].env`](#jobsjob_idstepsenv).
|
||||
|
||||
{% data reusables.repositories.actions-env-var-note %}
|
||||
|
||||
#### Example
|
||||
### Example
|
||||
|
||||
```yaml
|
||||
jobs:
|
||||
@@ -505,13 +505,13 @@ jobs:
|
||||
FIRST_NAME: Mona
|
||||
```
|
||||
|
||||
### `jobs.<job_id>.defaults`
|
||||
## `jobs.<job_id>.defaults`
|
||||
|
||||
A `map` of default settings that will apply to all steps in the job. You can also set default settings for the entire workflow. For more information, see [`defaults`](#defaults).
|
||||
|
||||
{% data reusables.github-actions.defaults-override %}
|
||||
|
||||
### `jobs.<job_id>.defaults.run`
|
||||
## `jobs.<job_id>.defaults.run`
|
||||
|
||||
Provide default `shell` and `working-directory` to all `run` steps in the job. Context and expression are not allowed in this section.
|
||||
|
||||
@@ -519,7 +519,7 @@ You can provide default `shell` and `working-directory` options for all [`run`](
|
||||
|
||||
{% data reusables.github-actions.defaults-override %}
|
||||
|
||||
#### Example
|
||||
### Example
|
||||
|
||||
```yaml
|
||||
jobs:
|
||||
@@ -531,19 +531,19 @@ jobs:
|
||||
working-directory: scripts
|
||||
```
|
||||
|
||||
### `jobs.<job_id>.if`
|
||||
## `jobs.<job_id>.if`
|
||||
|
||||
You can use the `if` conditional to prevent a job from running unless a condition is met. You can use any supported context and expression to create a conditional.
|
||||
|
||||
{% data reusables.github-actions.expression-syntax-if %} For more information, see "[Context and expression syntax for {% data variables.product.prodname_actions %}](/actions/reference/context-and-expression-syntax-for-github-actions)."
|
||||
|
||||
### `jobs.<job_id>.steps`
|
||||
## `jobs.<job_id>.steps`
|
||||
|
||||
A job contains a sequence of tasks called `steps`. Steps can run commands, run setup tasks, or run an action in your repository, a public repository, or an action published in a Docker registry. Not all steps run actions, but all actions run as a step. Each step runs in its own process in the runner environment and has access to the workspace and filesystem. Because steps run in their own process, changes to environment variables are not preserved between steps. {% data variables.product.prodname_dotcom %} provides built-in steps to set up and complete a job.
|
||||
|
||||
You can run an unlimited number of steps as long as you are within the workflow usage limits. For more information, see "[Usage limits and billing](/actions/reference/usage-limits-billing-and-administration)" for {% data variables.product.prodname_dotcom %}-hosted runners and "[About self-hosted runners](/actions/hosting-your-own-runners/about-self-hosted-runners/#usage-limits)" for self-hosted runner usage limits.
|
||||
|
||||
#### Example
|
||||
### Example
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
@@ -567,17 +567,17 @@ jobs:
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
### `jobs.<job_id>.steps[*].id`
|
||||
## `jobs.<job_id>.steps[*].id`
|
||||
|
||||
A unique identifier for the step. You can use the `id` to reference the step in contexts. For more information, see "[Context and expression syntax for {% data variables.product.prodname_actions %}](/actions/reference/context-and-expression-syntax-for-github-actions)."
|
||||
|
||||
### `jobs.<job_id>.steps[*].if`
|
||||
## `jobs.<job_id>.steps[*].if`
|
||||
|
||||
You can use the `if` conditional to prevent a step from running unless a condition is met. You can use any supported context and expression to create a conditional.
|
||||
|
||||
{% data reusables.github-actions.expression-syntax-if %} For more information, see "[Context and expression syntax for {% data variables.product.prodname_actions %}](/actions/reference/context-and-expression-syntax-for-github-actions)."
|
||||
|
||||
#### Example: Using contexts
|
||||
### Example: Using contexts
|
||||
|
||||
This step only runs when the event type is a `pull_request` and the event action is `unassigned`.
|
||||
|
||||
@@ -588,7 +588,7 @@ steps:
|
||||
run: echo This event is a pull request that had an assignee removed.
|
||||
```
|
||||
|
||||
#### Example: Using status check functions
|
||||
### Example: Using status check functions
|
||||
|
||||
The `my backup step` only runs when the previous step of a job fails. For more information, see "[Context and expression syntax for {% data variables.product.prodname_actions %}](/actions/reference/context-and-expression-syntax-for-github-actions#job-status-check-functions)."
|
||||
|
||||
@@ -601,11 +601,11 @@ steps:
|
||||
uses: actions/heroku@1.0.0
|
||||
```
|
||||
|
||||
### `jobs.<job_id>.steps[*].name`
|
||||
## `jobs.<job_id>.steps[*].name`
|
||||
|
||||
A name for your step to display on {% data variables.product.prodname_dotcom %}.
|
||||
|
||||
### `jobs.<job_id>.steps[*].uses`
|
||||
## `jobs.<job_id>.steps[*].uses`
|
||||
|
||||
Selects an action to run as part of a step in your job. An action is a reusable unit of code. You can use an action defined in the same repository as the workflow, a public repository, or in a [published Docker container image](https://hub.docker.com/).
|
||||
|
||||
@@ -618,7 +618,7 @@ Some actions require inputs that you must set using the [`with`](#jobsjob_idstep
|
||||
|
||||
Actions are either JavaScript files or Docker containers. If the action you're using is a Docker container you must run the job in a Linux environment. For more details, see [`runs-on`](#jobsjob_idruns-on).
|
||||
|
||||
#### Example: Using versioned actions
|
||||
### Example: Using versioned actions
|
||||
|
||||
```yaml
|
||||
steps:
|
||||
@@ -632,7 +632,7 @@ steps:
|
||||
- uses: actions/setup-node@main
|
||||
```
|
||||
|
||||
#### Example: Using a public action
|
||||
### Example: Using a public action
|
||||
|
||||
`{owner}/{repo}@{ref}`
|
||||
|
||||
@@ -650,7 +650,7 @@ jobs:
|
||||
uses: actions/aws@v2.0.1
|
||||
```
|
||||
|
||||
#### Example: Using a public action in a subdirectory
|
||||
### Example: Using a public action in a subdirectory
|
||||
|
||||
`{owner}/{repo}/{path}@{ref}`
|
||||
|
||||
@@ -664,7 +664,7 @@ jobs:
|
||||
uses: actions/aws/ec2@main
|
||||
```
|
||||
|
||||
#### Example: Using an action in the same repository as the workflow
|
||||
### Example: Using an action in the same repository as the workflow
|
||||
|
||||
`./path/to/dir`
|
||||
|
||||
@@ -680,7 +680,7 @@ jobs:
|
||||
uses: ./.github/actions/my-action
|
||||
```
|
||||
|
||||
#### Example: Using a Docker Hub action
|
||||
### Example: Using a Docker Hub action
|
||||
|
||||
`docker://{image}:{tag}`
|
||||
|
||||
@@ -695,7 +695,7 @@ jobs:
|
||||
```
|
||||
|
||||
{% if currentVersion == "free-pro-team@latest" %}
|
||||
##### Example: Using the {% data variables.product.prodname_registry %} {% data variables.product.prodname_container_registry %}
|
||||
#### Example: Using the {% data variables.product.prodname_registry %} {% data variables.product.prodname_container_registry %}
|
||||
|
||||
`docker://{host}/{image}:{tag}`
|
||||
|
||||
@@ -709,7 +709,7 @@ jobs:
|
||||
uses: docker://ghcr.io/OWNER/IMAGE_NAME
|
||||
```
|
||||
{% endif %}
|
||||
##### Example: Using a Docker public registry action
|
||||
#### Example: Using a Docker public registry action
|
||||
|
||||
`docker://{host}/{image}:{tag}`
|
||||
|
||||
@@ -723,7 +723,7 @@ jobs:
|
||||
uses: docker://gcr.io/cloud-builders/gradle
|
||||
```
|
||||
|
||||
#### Example: Using an action inside a different private repository than the workflow
|
||||
### Example: Using an action inside a different private repository than the workflow
|
||||
|
||||
Your workflow must checkout the private repository and reference the action locally. Generate a personal access token and add the token as an encrypted secret. For more information, see "[Creating a personal access token](/github/authenticating-to-github/creating-a-personal-access-token)" and "[Encrypted secrets](/actions/reference/encrypted-secrets)."
|
||||
|
||||
@@ -746,7 +746,7 @@ jobs:
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
### `jobs.<job_id>.steps[*].run`
|
||||
## `jobs.<job_id>.steps[*].run`
|
||||
|
||||
Runs command-line programs using the operating system's shell. If you do not provide a `name`, the step name will default to the text specified in the `run` command.
|
||||
|
||||
@@ -778,7 +778,7 @@ Using the `working-directory` keyword, you can specify the working directory of
|
||||
working-directory: ./temp
|
||||
```
|
||||
|
||||
#### Using a specific shell
|
||||
### Using a specific shell
|
||||
|
||||
You can override the default shell settings in the runner's operating system using the `shell` keyword. You can use built-in `shell` keywords, or you can define a custom set of shell options.
|
||||
|
||||
@@ -792,7 +792,7 @@ You can override the default shell settings in the runner's operating system usi
|
||||
| Windows | `pwsh` | This is the default shell used on Windows. The PowerShell Core. {% data variables.product.prodname_dotcom %} appends the extension `.ps1` to your script name. If your self-hosted Windows runner does not have _PowerShell Core_ installed, then _PowerShell Desktop_ is used instead.| `pwsh -command ". '{0}'"`. |
|
||||
| Windows | `powershell` | The PowerShell Desktop. {% data variables.product.prodname_dotcom %} appends the extension `.ps1` to your script name. | `powershell -command ". '{0}'"`. |
|
||||
|
||||
#### Example: Running a script using bash
|
||||
### Example: Running a script using bash
|
||||
|
||||
```yaml
|
||||
steps:
|
||||
@@ -801,7 +801,7 @@ steps:
|
||||
shell: bash
|
||||
```
|
||||
|
||||
#### Example: Running a script using Windows `cmd`
|
||||
### Example: Running a script using Windows `cmd`
|
||||
|
||||
```yaml
|
||||
steps:
|
||||
@@ -810,7 +810,7 @@ steps:
|
||||
shell: cmd
|
||||
```
|
||||
|
||||
#### Example: Running a script using PowerShell Core
|
||||
### Example: Running a script using PowerShell Core
|
||||
|
||||
```yaml
|
||||
steps:
|
||||
@@ -819,7 +819,7 @@ steps:
|
||||
shell: pwsh
|
||||
```
|
||||
|
||||
#### Example: Using PowerShell Desktop to run a script
|
||||
### Example: Using PowerShell Desktop to run a script
|
||||
|
||||
```yaml
|
||||
steps:
|
||||
@@ -828,7 +828,7 @@ steps:
|
||||
shell: powershell
|
||||
```
|
||||
|
||||
#### Example: Running a python script
|
||||
### Example: Running a python script
|
||||
|
||||
```yaml
|
||||
steps:
|
||||
@@ -839,7 +839,7 @@ steps:
|
||||
shell: python
|
||||
```
|
||||
|
||||
#### Custom shell
|
||||
### Custom shell
|
||||
|
||||
You can set the `shell` value to a template string using `command […options] {0} [..more_options]`. {% data variables.product.prodname_dotcom %} interprets the first whitespace-delimited word of the string as the command, and inserts the file name for the temporary script at `{0}`.
|
||||
|
||||
@@ -861,7 +861,7 @@ The command used, `perl` in this example, must be installed on the runner.
|
||||
For information about the software included on GitHub-hosted runners, see "[Specifications for GitHub-hosted runners](/actions/reference/specifications-for-github-hosted-runners#supported-software)."
|
||||
{% endif %}
|
||||
|
||||
#### Exit codes and error action preference
|
||||
### Exit codes and error action preference
|
||||
|
||||
For built-in shell keywords, we provide the following defaults that are executed by {% data variables.product.prodname_dotcom %}-hosted runners. You should use these guidelines when running shell scripts.
|
||||
|
||||
@@ -879,11 +879,11 @@ For built-in shell keywords, we provide the following defaults that are executed
|
||||
- There doesn't seem to be a way to fully opt into fail-fast behavior other than writing your script to check each error code and respond accordingly. Because we can't actually provide that behavior by default, you need to write this behavior into your script.
|
||||
- `cmd.exe` will exit with the error level of the last program it executed, and it will return the error code to the runner. This behavior is internally consistent with the previous `sh` and `pwsh` default behavior and is the `cmd.exe` default, so this behavior remains intact.
|
||||
|
||||
### `jobs.<job_id>.steps[*].with`
|
||||
## `jobs.<job_id>.steps[*].with`
|
||||
|
||||
A `map` of the input parameters defined by the action. Each input parameter is a key/value pair. Input parameters are set as environment variables. The variable is prefixed with `INPUT_` and converted to upper case.
|
||||
|
||||
#### Example
|
||||
### Example
|
||||
|
||||
Defines the three input parameters (`first_name`, `middle_name`, and `last_name`) defined by the `hello_world` action. These input variables will be accessible to the `hello-world` action as `INPUT_FIRST_NAME`, `INPUT_MIDDLE_NAME`, and `INPUT_LAST_NAME` environment variables.
|
||||
|
||||
@@ -899,11 +899,11 @@ jobs:
|
||||
last_name: Octocat
|
||||
```
|
||||
|
||||
### `jobs.<job_id>.steps[*].with.args`
|
||||
## `jobs.<job_id>.steps[*].with.args`
|
||||
|
||||
A `string` that defines the inputs for a Docker container. {% data variables.product.prodname_dotcom %} passes the `args` to the container's `ENTRYPOINT` when the container starts up. An `array of strings` is not supported by this parameter.
|
||||
|
||||
#### Example
|
||||
### Example
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
@@ -922,11 +922,11 @@ The `args` are used in place of the `CMD` instruction in a `Dockerfile`. If you
|
||||
1. Use defaults that allow using the action without specifying any `args`.
|
||||
1. If the action exposes a `--help` flag, or something similar, use that as the default to make your action self-documenting.
|
||||
|
||||
### `jobs.<job_id>.steps[*].with.entrypoint`
|
||||
## `jobs.<job_id>.steps[*].with.entrypoint`
|
||||
|
||||
Overrides the Docker `ENTRYPOINT` in the `Dockerfile`, or sets it if one wasn't already specified. Unlike the Docker `ENTRYPOINT` instruction which has a shell and exec form, `entrypoint` keyword accepts only a single string defining the executable to be run.
|
||||
|
||||
#### Example
|
||||
### Example
|
||||
|
||||
```yaml
|
||||
steps:
|
||||
@@ -938,7 +938,7 @@ steps:
|
||||
|
||||
The `entrypoint` keyword is meant to be used with Docker container actions, but you can also use it with JavaScript actions that don't define any inputs.
|
||||
|
||||
### `jobs.<job_id>.steps[*].env`
|
||||
## `jobs.<job_id>.steps[*].env`
|
||||
|
||||
Sets environment variables for steps to use in the runner environment. You can also set environment variables for the entire workflow or a job. For more information, see [`env`](#env) and [`jobs.<job_id>.env`](#jobsjob_idenv).
|
||||
|
||||
@@ -946,7 +946,7 @@ Sets environment variables for steps to use in the runner environment. You can a
|
||||
|
||||
Public actions may specify expected environment variables in the README file. If you are setting a secret in an environment variable, you must set secrets using the `secrets` context. For more information, see "[Using environment variables](/actions/automating-your-workflow-with-github-actions/using-environment-variables)" and "[Context and expression syntax for {% data variables.product.prodname_actions %}](/actions/reference/context-and-expression-syntax-for-github-actions)."
|
||||
|
||||
#### Example
|
||||
### Example
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
@@ -959,23 +959,23 @@ steps:
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
### `jobs.<job_id>.steps[*].continue-on-error`
|
||||
## `jobs.<job_id>.steps[*].continue-on-error`
|
||||
|
||||
Prevents a job from failing when a step fails. Set to `true` to allow a job to pass when this step fails.
|
||||
|
||||
### `jobs.<job_id>.steps[*].timeout-minutes`
|
||||
## `jobs.<job_id>.steps[*].timeout-minutes`
|
||||
|
||||
The maximum number of minutes to run the step before killing the process.
|
||||
|
||||
### `jobs.<job_id>.timeout-minutes`
|
||||
## `jobs.<job_id>.timeout-minutes`
|
||||
|
||||
The maximum number of minutes to let a job run before {% data variables.product.prodname_dotcom %} automatically cancels it. Default: 360
|
||||
|
||||
### `jobs.<job_id>.strategy`
|
||||
## `jobs.<job_id>.strategy`
|
||||
|
||||
A strategy creates a build matrix for your jobs. You can define different variations to run each job in.
|
||||
|
||||
### `jobs.<job_id>.strategy.matrix`
|
||||
## `jobs.<job_id>.strategy.matrix`
|
||||
|
||||
You can 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.
|
||||
|
||||
@@ -985,7 +985,7 @@ Each option you define in the `matrix` has a key and value. The keys you define
|
||||
|
||||
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
|
||||
### 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`.
|
||||
|
||||
@@ -1007,7 +1007,7 @@ steps:
|
||||
|
||||
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
|
||||
### 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:
|
||||
|
||||
@@ -1034,7 +1034,7 @@ steps:
|
||||
{% 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 into combinations
|
||||
### Example: Including additional values into 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.
|
||||
|
||||
@@ -1054,7 +1054,7 @@ strategy:
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
#### Example: Including new combinations
|
||||
### 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.
|
||||
|
||||
@@ -1072,7 +1072,7 @@ strategy:
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
#### Example: Excluding configurations from a matrix
|
||||
### 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`).
|
||||
|
||||
@@ -1096,17 +1096,17 @@ strategy:
|
||||
|
||||
{% endnote %}
|
||||
|
||||
##### Using environment variables in a matrix
|
||||
#### 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.github-actions.matrix-variable-example %}
|
||||
|
||||
### `jobs.<job_id>.strategy.fail-fast`
|
||||
## `jobs.<job_id>.strategy.fail-fast`
|
||||
|
||||
When set to `true`, {% data variables.product.prodname_dotcom %} cancels all in-progress jobs if any `matrix` job fails. Default: `true`
|
||||
|
||||
### `jobs.<job_id>.strategy.max-parallel`
|
||||
## `jobs.<job_id>.strategy.max-parallel`
|
||||
|
||||
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.
|
||||
|
||||
@@ -1115,11 +1115,11 @@ strategy:
|
||||
max-parallel: 2
|
||||
```
|
||||
|
||||
### `jobs.<job_id>.continue-on-error`
|
||||
## `jobs.<job_id>.continue-on-error`
|
||||
|
||||
Prevents a workflow run from failing when a job fails. Set to `true` to allow a workflow run to pass when this job fails.
|
||||
|
||||
#### Example: Preventing a specific failing matrix job from failing a workflow run
|
||||
### Example: Preventing a specific failing matrix job from failing a workflow run
|
||||
|
||||
You can allow specific jobs in a job matrix to fail without failing the workflow run. For example, if you wanted to only allow an experimental job with `node` set to `15` to fail without failing the workflow run.
|
||||
|
||||
@@ -1140,13 +1140,13 @@ strategy:
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
### `jobs.<job_id>.container`
|
||||
## `jobs.<job_id>.container`
|
||||
|
||||
A container to run any steps in a job that don't already specify a container. If you have steps that use both script and container actions, the container actions will run as sibling containers on the same network with the same volume mounts.
|
||||
|
||||
If you do not set a `container`, all steps will run directly on the host specified by `runs-on` unless a step refers to an action configured to run in a container.
|
||||
|
||||
#### Example
|
||||
### Example
|
||||
|
||||
```yaml
|
||||
jobs:
|
||||
@@ -1170,17 +1170,17 @@ jobs:
|
||||
container: node:14.16
|
||||
```
|
||||
|
||||
### `jobs.<job_id>.container.image`
|
||||
## `jobs.<job_id>.container.image`
|
||||
|
||||
The Docker image to use as the container to run the action. The value can be the Docker Hub image name or a {% if enterpriseServerVersions contains currentVersion and currentVersion ver_lt "enterprise-server@2.23" %}public{% endif %} registry name.
|
||||
|
||||
{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@2.22" or currentVersion == "github-ae@latest" %}
|
||||
|
||||
### `jobs.<job_id>.container.credentials`
|
||||
## `jobs.<job_id>.container.credentials`
|
||||
|
||||
{% data reusables.actions.registry-credentials %}
|
||||
|
||||
#### Example
|
||||
### Example
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
@@ -1193,15 +1193,15 @@ container:
|
||||
{% endraw %}
|
||||
{% endif %}
|
||||
|
||||
### `jobs.<job_id>.container.env`
|
||||
## `jobs.<job_id>.container.env`
|
||||
|
||||
Sets a `map` of environment variables in the container.
|
||||
|
||||
### `jobs.<job_id>.container.ports`
|
||||
## `jobs.<job_id>.container.ports`
|
||||
|
||||
Sets an `array` of ports to expose on the container.
|
||||
|
||||
### `jobs.<job_id>.container.volumes`
|
||||
## `jobs.<job_id>.container.volumes`
|
||||
|
||||
Sets an `array` of volumes for the container to use. You can use volumes to share data between services or other steps in a job. You can specify named Docker volumes, anonymous Docker volumes, or bind mounts on the host.
|
||||
|
||||
@@ -1211,7 +1211,7 @@ To specify a volume, you specify the source and destination path:
|
||||
|
||||
The `<source>` is a volume name or an absolute path on the host machine, and `<destinationPath>` is an absolute path in the container.
|
||||
|
||||
#### Example
|
||||
### Example
|
||||
|
||||
```yaml
|
||||
volumes:
|
||||
@@ -1220,11 +1220,11 @@ volumes:
|
||||
- /source/directory:/destination/directory
|
||||
```
|
||||
|
||||
### `jobs.<job_id>.container.options`
|
||||
## `jobs.<job_id>.container.options`
|
||||
|
||||
Additional Docker container resource options. For a list of options, see "[`docker create` options](https://docs.docker.com/engine/reference/commandline/create/#options)."
|
||||
|
||||
### `jobs.<job_id>.services`
|
||||
## `jobs.<job_id>.services`
|
||||
|
||||
{% data reusables.github-actions.docker-container-os-support %}
|
||||
|
||||
@@ -1236,7 +1236,7 @@ If you configure the job to run directly on the runner machine and your step doe
|
||||
|
||||
For more information about the differences between networking service containers, see "[About service containers](/actions/automating-your-workflow-with-github-actions/about-service-containers)."
|
||||
|
||||
#### Example: Using localhost
|
||||
### Example: Using localhost
|
||||
|
||||
This example creates two services: nginx and redis. When you specify the Docker host port but not the container port, the container port is randomly assigned to a free port. {% data variables.product.prodname_dotcom %} sets the assigned container port in the {% raw %}`${{job.services.<service_name>.ports}}`{% endraw %} context. In this example, you can access the service container ports using the {% raw %}`${{ job.services.nginx.ports['8080'] }}`{% endraw %} and {% raw %}`${{ job.services.redis.ports['6379'] }}`{% endraw %} contexts.
|
||||
|
||||
@@ -1254,17 +1254,17 @@ services:
|
||||
- 6379/tcp
|
||||
```
|
||||
|
||||
### `jobs.<job_id>.services.<service_id>.image`
|
||||
## `jobs.<job_id>.services.<service_id>.image`
|
||||
|
||||
The Docker image to use as the service container to run the action. The value can be the Docker Hub image name or a {% if enterpriseServerVersions contains currentVersion and currentVersion ver_lt "enterprise-server@2.23" %}public{% endif %} registry name.
|
||||
|
||||
{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@2.22" or currentVersion == "github-ae@latest" %}
|
||||
|
||||
### `jobs.<job_id>.services.<service_id>.credentials`
|
||||
## `jobs.<job_id>.services.<service_id>.credentials`
|
||||
|
||||
{% data reusables.actions.registry-credentials %}
|
||||
|
||||
#### Example
|
||||
### Example
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
@@ -1283,15 +1283,15 @@ services:
|
||||
{% endraw %}
|
||||
{% endif %}
|
||||
|
||||
### `jobs.<job_id>.services.<service_id>.env`
|
||||
## `jobs.<job_id>.services.<service_id>.env`
|
||||
|
||||
Sets a `map` of environment variables in the service container.
|
||||
|
||||
### `jobs.<job_id>.services.<service_id>.ports`
|
||||
## `jobs.<job_id>.services.<service_id>.ports`
|
||||
|
||||
Sets an `array` of ports to expose on the service container.
|
||||
|
||||
### `jobs.<job_id>.services.<service_id>.volumes`
|
||||
## `jobs.<job_id>.services.<service_id>.volumes`
|
||||
|
||||
Sets an `array` of volumes for the service container to use. You can use volumes to share data between services or other steps in a job. You can specify named Docker volumes, anonymous Docker volumes, or bind mounts on the host.
|
||||
|
||||
@@ -1301,7 +1301,7 @@ To specify a volume, you specify the source and destination path:
|
||||
|
||||
The `<source>` is a volume name or an absolute path on the host machine, and `<destinationPath>` is an absolute path in the container.
|
||||
|
||||
#### Example
|
||||
### Example
|
||||
|
||||
```yaml
|
||||
volumes:
|
||||
@@ -1310,11 +1310,11 @@ volumes:
|
||||
- /source/directory:/destination/directory
|
||||
```
|
||||
|
||||
### `jobs.<job_id>.services.<service_id>.options`
|
||||
## `jobs.<job_id>.services.<service_id>.options`
|
||||
|
||||
Additional Docker container resource options. For a list of options, see "[`docker create` options](https://docs.docker.com/engine/reference/commandline/create/#options)."
|
||||
|
||||
### Filter pattern cheat sheet
|
||||
## Filter pattern cheat sheet
|
||||
|
||||
You can use special characters in path, branch, and tag filters.
|
||||
|
||||
@@ -1338,7 +1338,7 @@ The characters `*`, `[`, and `!` are special characters in YAML. If you start a
|
||||
|
||||
For more information about branch, tag, and path filter syntax, see "[`on.<push|pull_request>.<branches|tags>`](#onpushpull_requestbranchestags)" and "[`on.<push|pull_request>.paths`](#onpushpull_requestpaths)."
|
||||
|
||||
#### Patterns to match branches and tags
|
||||
### Patterns to match branches and tags
|
||||
|
||||
| Pattern | Description | Example matches |
|
||||
|---------|------------------------|---------|
|
||||
@@ -1351,7 +1351,7 @@ For more information about branch, tag, and path filter syntax, see "[`on.<push|
|
||||
| `v2*` | Matches branch and tag names that start with `v2`. | `v2`<br/><br/>`v2.0`<br/><br/>`v2.9` |
|
||||
| `v[12].[0-9]+.[0-9]+` | Matches all semantic versioning branches and tags with major version 1 or 2 | `v1.10.1`<br/><br/>`v2.0.0` |
|
||||
|
||||
#### Patterns to match file paths
|
||||
### Patterns to match file paths
|
||||
|
||||
Path patterns must match the whole path, and start from the repository's root.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user