{"meta":{"title":"GitHub Actions　のワークフロー構文","intro":"ワークフローは、1 つ以上のジョブからなる設定可能な自動化プロセスです。 ワークフローの設定を定義するには、YAMLファイルを作成しなければなりません。","product":"GitHub Actions","breadcrumbs":[{"href":"/ja/enterprise-cloud@latest/actions","title":"GitHub Actions"},{"href":"/ja/enterprise-cloud@latest/actions/reference","title":"リファレンス"},{"href":"/ja/enterprise-cloud@latest/actions/reference/workflows-and-actions","title":"ワークフローとアクション"},{"href":"/ja/enterprise-cloud@latest/actions/reference/workflows-and-actions/workflow-syntax","title":"ワークフロー構文"}],"documentType":"article"},"body":"# GitHub Actions　のワークフロー構文\n\nワークフローは、1 つ以上のジョブからなる設定可能な自動化プロセスです。 ワークフローの設定を定義するには、YAMLファイルを作成しなければなりません。\n\n<!-- TRANSLATION_FALLBACK prop=markdown type=ParseError line=35 col=15 msg=\"tag {% ifversion vulnerability-alerts-permission %} not closed\" -->\n## About YAML syntax for workflows\n\nWorkflow files use YAML syntax, and must have either a `.yml` or `.yaml` file extension. If you're new to YAML and want to learn more, see [Learn YAML in Y minutes](https://learnxinyminutes.com/docs/yaml/).\n\nYou must store workflow files in the `.github/workflows` directory of your repository.\n\n## `name`\n\nThe name of the workflow. GitHub displays the names of your workflows under your repository's \"Actions\" tab. If you omit `name`, GitHub displays the workflow file path relative to the root of the repository.\n\n## `run-name`\n\nThe name for workflow runs generated from the workflow. GitHub displays the workflow run name in the list of workflow runs on your repository's \"Actions\" tab. If `run-name` is omitted or is only whitespace, then the run name is set to event-specific information for the workflow run. For example, for a workflow triggered by a `push` or `pull_request` event, it is set as the commit message or the title of the pull request.\n\nThis value can include expressions and can reference the [`github`](/en/enterprise-cloud@latest/actions/learn-github-actions/contexts#github-context) and [`inputs`](/en/enterprise-cloud@latest/actions/learn-github-actions/contexts#inputs-context) contexts.\n\n### Example of `run-name`\n\n```yaml\nrun-name: Deploy to ${{ inputs.deploy_target }} by @${{ github.actor }}\n```\n\n## `on`\n\nTo automatically trigger a workflow, use `on` to define which events can cause the workflow to run. For a list of available events, see [Events that trigger workflows](/en/enterprise-cloud@latest/actions/using-workflows/events-that-trigger-workflows).\n\nYou can define single or multiple events that can trigger a workflow, or set a time schedule. You can also restrict the execution of a workflow to only occur for specific files, tags, or branch changes. These options are described in the following sections.\n\n### Using a single event\n\nFor example, a workflow with the following `on` value will run when a push is made to any branch in the workflow's repository:\n\n```yaml\non: push\n```\n\n### Using multiple events\n\nYou can specify a single event or multiple events. For example, a workflow with the following `on` value will run when a push is made to any branch in the repository or when someone forks the repository:\n\n```yaml\non: [push, fork]\n```\n\nIf you specify multiple events, only one of those events needs to occur to trigger your workflow. If multiple triggering events for your workflow occur at the same time, multiple workflow runs will be triggered.\n\n### Using activity types\n\nSome events have activity types that give you more control over when your workflow should run. Use `on.<event_name>.types` to define the type of event activity that will trigger a workflow run.\n\nFor example, the `issue_comment` event has the `created`, `edited`, and `deleted` activity types. If your workflow triggers on the `label` event, it will run whenever a label is created, edited, or deleted. If you specify the `created` activity type for the `label` event, your workflow will run when a label is created but not when a label is edited or deleted.\n\n```yaml\non:\n  label:\n    types:\n      - created\n```\n\nIf you specify multiple activity types, only one of those event activity types needs to occur to trigger your workflow. If multiple triggering event activity types for your workflow occur at the same time, multiple workflow runs will be triggered. For example, the following workflow triggers when an issue is opened or labeled. If an issue with two labels is opened, three workflow runs will start: one for the issue opened event and two for the two issue labeled events.\n\n```yaml\non:\n  issues:\n    types:\n      - opened\n      - labeled\n```\n\nFor more information about each event and their activity types, see [Events that trigger workflows](/en/enterprise-cloud@latest/actions/using-workflows/events-that-trigger-workflows).\n\n### Using filters\n\nSome events have filters that give you more control over when your workflow should run.\n\nFor example, the `push` event has a `branches` filter that causes your workflow to run only when a push to a branch that matches the `branches` filter occurs, instead of when any push occurs.\n\n```yaml\non:\n  push:\n    branches:\n      - main\n      - 'releases/**'\n```\n\n### Using activity types and filters with multiple events\n\nIf you specify activity types or filters for an event and your workflow triggers on multiple events, you must configure each event separately. You must append a colon (`:`) to all events, including events without configuration.\n\nFor example, a workflow with the following `on` value will run when:\n\n* A label is created\n* A push is made to the `main` branch in the repository\n* A push is made to a GitHub Pages-enabled branch\n\n```yaml\non:\n  label:\n    types:\n      - created\n  push:\n    branches:\n      - main\n  page_build:\n```\n\n## `on.<event_name>.types`\n\nUse `on.<event_name>.types` to define the type of activity that will trigger a workflow run. Most GitHub events are triggered by more than one type of activity. For example, the `label` is triggered when a label is `created`, `edited`, or `deleted`. 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.\n\nYou can use an array of event `types`. For more information about each event and their activity types, see [Events that trigger workflows](/en/enterprise-cloud@latest/actions/using-workflows/events-that-trigger-workflows#available-events).\n\n```yaml\non:\n  label:\n    types: [created, edited]\n```\n\n## `on.<pull_request|pull_request_target>.<branches|branches-ignore>`\n\nWhen using the `pull_request` and `pull_request_target` events, you can configure a workflow to run only for pull requests that target specific branches.\n\nUse the `branches` filter when you want to include branch name patterns or when you want to both include and exclude branch names patterns. Use the `branches-ignore` filter when you only want to exclude branch name patterns. You cannot use both the `branches` and `branches-ignore` filters for the same event in a workflow.\n\nIf you define both `branches`/`branches-ignore` and [`paths`/`paths-ignore`](/en/enterprise-cloud@latest/actions/using-workflows/workflow-syntax-for-github-actions#onpushpull_requestpull_request_targetpathspaths-ignore), the workflow will only run when both filters are satisfied.\n\nThe `branches` and `branches-ignore` keywords accept glob patterns that use characters like `*`, `**`, `+`, `?`, `!` and others to match more than one branch name. If a name contains any of these characters and you want a literal match, you need to escape each of these special characters with `\\`. For more information about glob patterns, see the [Workflow syntax for GitHub Actions](/en/enterprise-cloud@latest/actions/using-workflows/workflow-syntax-for-github-actions#filter-pattern-cheat-sheet).\n\n### Example: Including branches\n\nThe patterns defined in `branches` are evaluated against the Git ref's name. For example, the following workflow would run whenever there is a `pull_request` event for a pull request targeting:\n\n* A branch named `main` (`refs/heads/main`)\n* A branch named `mona/octocat` (`refs/heads/mona/octocat`)\n* A branch whose name starts with `releases/`, like `releases/10` (`refs/heads/releases/10`)\n\n```yaml\non:\n  pull_request:\n    # Sequence of patterns matched against refs/heads\n    branches:\n      - main\n      - 'mona/octocat'\n      - 'releases/**'\n```\n\nYou should not use path or branch filtering to skip workflow runs if the workflow is required to pass before merging. For more information, see [Skipping workflow runs](/en/enterprise-cloud@latest/actions/managing-workflow-runs/skipping-workflow-runs) and [Available rules for rulesets](/en/enterprise-cloud@latest/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/available-rules-for-rulesets#require-workflows-to-pass-before-merging).\n\nIf a workflow is skipped due to branch filtering, [path filtering](/en/enterprise-cloud@latest/actions/using-workflows/workflow-syntax-for-github-actions#onpushpull_requestpull_request_targetpathspaths-ignore), or a [commit message](/en/enterprise-cloud@latest/actions/managing-workflow-runs/skipping-workflow-runs), then checks associated with that workflow will remain in a \"Pending\" state. A pull request that requires those checks to be successful will be blocked from merging.\n\n### Example: Excluding branches\n\nWhen a pattern matches the `branches-ignore` pattern, the workflow will not run. The patterns defined in `branches-ignore` are evaluated against the Git ref's name. For example, the following workflow would run whenever there is a `pull_request` event unless the pull request is targeting:\n\n* A branch named `mona/octocat` (`refs/heads/mona/octocat`)\n* A branch whose name matches `releases/**-alpha`, like `releases/beta/3-alpha` (`refs/heads/releases/beta/3-alpha`) <!-- markdownlint-disable-line outdated-release-phase-terminology -->\n\n```yaml\non:\n  pull_request:\n    # Sequence of patterns matched against refs/heads\n    branches-ignore:\n      - 'mona/octocat'\n      - 'releases/**-alpha'\n```\n\n### Example: Including and excluding branches\n\nYou cannot use `branches` and `branches-ignore` to filter the same event in a single workflow. If you want to both include and exclude branch patterns for a single event, use the `branches` filter along with the `!` character to indicate which branches should be excluded.\n\nIf you define a branch with the `!` character, you must also define at least one branch without the `!` character. If you only want to exclude branches, use `branches-ignore` instead.\n\nThe order that you define patterns matters.\n\n* A matching negative pattern (prefixed with `!`) after a positive match will exclude the Git ref.\n* A matching positive pattern after a negative match will include the Git ref again.\n\nThe following workflow will run on `pull_request` events for pull requests that target `releases/10` or `releases/beta/mona`, but not for pull requests that target `releases/10-alpha` or `releases/beta/3-alpha` because the negative pattern `!releases/**-alpha` follows the positive pattern. <!-- markdownlint-disable-line outdated-release-phase-terminology -->\n\n```yaml\non:\n  pull_request:\n    branches:\n      - 'releases/**'\n      - '!releases/**-alpha'\n```\n\n## `on.push.<branches|tags|branches-ignore|tags-ignore>`\n\nWhen using the `push` event, you can configure a workflow to run on specific branches or tags.\n\nUse the `branches` filter when you want to include branch name patterns or when you want to both include and exclude branch names patterns. Use the `branches-ignore` filter when you only want to exclude branch name patterns. You cannot use both the `branches` and `branches-ignore` filters for the same event in a workflow.\n\nUse the `tags` filter when you want to include tag name patterns or when you want to both include and exclude tag names patterns. Use the `tags-ignore` filter when you only want to exclude tag name patterns. You cannot use both the `tags` and `tags-ignore` filters for the same event in a workflow.\n\nIf you define only `tags`/`tags-ignore` or only `branches`/`branches-ignore`, the workflow won't run for events affecting the undefined Git ref. If you define neither `tags`/`tags-ignore` or `branches`/`branches-ignore`, the workflow will run for events affecting either branches or tags. If you define both `branches`/`branches-ignore` and [`paths`/`paths-ignore`](/en/enterprise-cloud@latest/actions/using-workflows/workflow-syntax-for-github-actions#onpushpull_requestpull_request_targetpathspaths-ignore), the workflow will only run when both filters are satisfied.\n\nThe `branches`, `branches-ignore`, `tags`, and `tags-ignore` keywords accept glob patterns that use characters like `*`, `**`, `+`, `?`, `!` and others to match more than one branch or tag name. If a name contains any of these characters and you want a literal match, you need to *escape* each of these special characters with `\\`. For more information about glob patterns, see the [Workflow syntax for GitHub Actions](/en/enterprise-cloud@latest/actions/using-workflows/workflow-syntax-for-github-actions#filter-pattern-cheat-sheet).\n\n### Example: Including branches and tags\n\nThe patterns defined in `branches` and `tags` are evaluated against the Git ref's name. For example, the following workflow would run whenever there is a `push` event to:\n\n* A branch named `main` (`refs/heads/main`)\n* A branch named `mona/octocat` (`refs/heads/mona/octocat`)\n* A branch whose name starts with `releases/`, like `releases/10` (`refs/heads/releases/10`)\n* A tag named `v2` (`refs/tags/v2`)\n* A tag whose name starts with `v1.`, like `v1.9.1` (`refs/tags/v1.9.1`)\n\n```yaml\non:\n  push:\n    # Sequence of patterns matched against refs/heads\n    branches:\n      - main\n      - 'mona/octocat'\n      - 'releases/**'\n    # Sequence of patterns matched against refs/tags\n    tags:\n      - v2\n      - v1.*\n```\n\n### Example: Excluding branches and tags\n\nWhen a pattern matches the `branches-ignore` or `tags-ignore` pattern, the workflow will not run. The patterns defined in `branches` and `tags` are evaluated against the Git ref's name. For example, the following workflow would run whenever there is a `push` event, unless the `push` event is to:\n\n* A branch named `mona/octocat` (`refs/heads/mona/octocat`)\n* A branch whose name matches `releases/**-alpha`, like `releases/beta/3-alpha` (`refs/heads/releases/beta/3-alpha`) <!-- markdownlint-disable-line outdated-release-phase-terminology -->\n* A tag named `v2` (`refs/tags/v2`)\n* A tag whose name starts with `v1.`, like `v1.9` (`refs/tags/v1.9`)\n\n```yaml\non:\n  push:\n    # Sequence of patterns matched against refs/heads\n    branches-ignore:\n      - 'mona/octocat'\n      - 'releases/**-alpha'\n    # Sequence of patterns matched against refs/tags\n    tags-ignore:\n      - v2\n      - v1.*\n```\n\n### Example: Including and excluding branches and tags\n\nYou can't use `branches` and `branches-ignore` to filter the same event in a single workflow. Similarly, you can't use `tags` and `tags-ignore` to filter the same event in a single workflow. If you want to both include and exclude branch or tag patterns for a single event, use the `branches` or `tags` filter along with the `!` character to indicate which branches or tags should be excluded.\n\nIf you define a branch with the `!` character, you must also define at least one branch without the `!` character. If you only want to exclude branches, use `branches-ignore` instead. Similarly, if you define a tag with the `!` character, you must also define at least one tag without the `!` character. If you only want to exclude tags, use `tags-ignore` instead.\n\nThe order that you define patterns matters.\n\n* A matching negative pattern (prefixed with `!`) after a positive match will exclude the Git ref.\n* A matching positive pattern after a negative match will include the Git ref again.\n\nThe following workflow will run on pushes to `releases/10` or `releases/beta/mona`, but not on `releases/10-alpha` or `releases/beta/3-alpha` because the negative pattern `!releases/**-alpha` follows the positive pattern. <!-- markdownlint-disable-line outdated-release-phase-terminology -->\n\n```yaml\non:\n  push:\n    branches:\n      - 'releases/**'\n      - '!releases/**-alpha'\n```\n\n## `on.<push|pull_request|pull_request_target>.<paths|paths-ignore>`\n\nWhen using the `push` and `pull_request` events, you can configure a workflow to run based on what file paths are changed. Path filters are not evaluated for pushes of tags.\n\nUse the `paths` filter when you want to include file path patterns or when you want to both include and exclude file path patterns. Use the `paths-ignore` filter when you only want to exclude file path patterns. You cannot use both the `paths` and `paths-ignore` filters for the same event in a workflow. If you want to both include and exclude path patterns for a single event, use the `paths` filter prefixed with the `!` character to indicate which paths should be excluded.\n\n> \\[!NOTE]\n> The order that you define `paths` patterns matters:\n>\n> * A matching negative pattern (prefixed with `!`) after a positive match will exclude the path.\n> * A matching positive pattern after a negative match will include the path again.\n\nIf you define both `branches`/`branches-ignore` and `paths`/`paths-ignore`, the workflow will only run when both filters are satisfied.\n\nThe `paths` and `paths-ignore` keywords accept glob patterns that use the `*` and `**` wildcard characters to match more than one path name. For more information, see the [Workflow syntax for GitHub Actions](/en/enterprise-cloud@latest/actions/using-workflows/workflow-syntax-for-github-actions#filter-pattern-cheat-sheet).\n\n### Example: Including paths\n\nIf at least one path matches a pattern in the `paths` filter, the workflow runs. For example, the following workflow would run anytime you push a JavaScript file (`.js`).\n\n```yaml\non:\n  push:\n    paths:\n      - '**.js'\n```\n\nYou should not use path or branch filtering to skip workflow runs if the workflow is required to pass before merging. For more information, see [Skipping workflow runs](/en/enterprise-cloud@latest/actions/managing-workflow-runs/skipping-workflow-runs) and [Available rules for rulesets](/en/enterprise-cloud@latest/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/available-rules-for-rulesets#require-workflows-to-pass-before-merging).\n\nIf a workflow is skipped due to path filtering, [branch filtering](/en/enterprise-cloud@latest/actions/using-workflows/workflow-syntax-for-github-actions#onpull_requestpull_request_targetbranchesbranches-ignore), or a [commit message](/en/enterprise-cloud@latest/actions/managing-workflow-runs/skipping-workflow-runs), then checks associated with that workflow will remain in a \"Pending\" state. A pull request that requires those checks to be successful will be blocked from merging.\n\n### Example: Excluding paths\n\nWhen all the path names match patterns in `paths-ignore`, the workflow will not run. If any path names do not match patterns in `paths-ignore`, even if some path names match the patterns, the workflow will run.\n\nA 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.\n\n```yaml\non:\n  push:\n    paths-ignore:\n      - 'docs/**'\n```\n\n### Example: Including and excluding paths\n\nYou cannot use `paths` and `paths-ignore` to filter the same event in a single workflow. If you want to both include and exclude path patterns for a single event, use the `paths` filter prefixed with the `!` character to indicate which paths should be excluded.\n\nIf you define a path with the `!` character, you must also define at least one path without the `!` character. If you only want to exclude paths, use `paths-ignore` instead.\n\nThe order that you define `paths` patterns matters:\n\n* A matching negative pattern (prefixed with `!`) after a positive match will exclude the path.\n* A matching positive pattern after a negative match will include the path again.\n\nThis example runs anytime the `push` event includes a file in the `sub-project` directory or its subdirectories, unless the file is in the `sub-project/docs` directory. For example, a push that changed `sub-project/index.js` or `sub-project/src/index.js` will trigger a workflow run, but a push changing only `sub-project/docs/readme.md` will not.\n\n```yaml\non:\n  push:\n    paths:\n      - 'sub-project/**'\n      - '!sub-project/docs/**'\n```\n\n### Git diff comparisons\n\n> \\[!NOTE]\n> If you push more than 1,000 commits, or if GitHub does not generate the diff due to a timeout, the workflow will always run.\n\nThe filter determines if a workflow should run by evaluating the changed files and running them against the `paths-ignore` or `paths` list. If there are no files changed, the workflow will not run.\n\nGitHub generates the list of changed files using two-dot diffs for pushes and three-dot diffs for pull requests:\n\n* **Pull requests:** Three-dot diffs are a comparison between the most recent version of the topic branch and the commit where the topic branch was last synced with the base branch.\n* **Pushes to existing branches:** A two-dot diff compares the head and base SHAs directly with each other.\n* **Pushes to new branches:** A two-dot diff against the parent of the ancestor of the deepest commit pushed.\n\n> \\[!NOTE]\n> Diffs are limited to 300 files. If there are files changed that aren't matched in the first 300 files returned by the filter, the workflow will not run. You may need to create more specific filters so that the workflow will run automatically.\n\nFor more information, see [About comparing branches in pull requests](/en/enterprise-cloud@latest/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-comparing-branches-in-pull-requests).\n\n## `on.schedule`\n\nYou can use `on.schedule` to define a time schedule for your workflows.\n\nUse [POSIX cron syntax](https://pubs.opengroup.org/onlinepubs/9699919799/utilities/crontab.html#tag_20_25_07) to schedule workflows to run at specific times. By default, scheduled workflows run in UTC. You can optionally specify a timezone using an [IANA timezone string](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones) for timezone-aware scheduling. Scheduled workflows run on the latest commit on the default branch. The shortest interval you can run scheduled workflows is once every 5 minutes.\n\n> \\[!NOTE]\n> For schedules that set `timezone` to a time zone that observes daylight saving time (DST), during DST spring-forward transitions, scheduled workflows in skipped hours advance to the next valid time. For example, a 2:30 AM schedule advances to 3:00 AM.\n\nCron syntax has five fields separated by a space, and each field represents a unit of time.\n\n```text\n┌───────────── minute (0 - 59)\n│ ┌───────────── hour (0 - 23)\n│ │ ┌───────────── day of the month (1 - 31)\n│ │ │ ┌───────────── month (1 - 12 or JAN-DEC)\n│ │ │ │ ┌───────────── day of the week (0 - 6 or SUN-SAT)\n│ │ │ │ │\n* * * * *\n```\n\nYou can use these operators in any of the five fields:\n\n| Operator | Description          | Example                                                                                            |\n| -------- | -------------------- | -------------------------------------------------------------------------------------------------- |\n| \\*       | Any value            | `15 * * * *` runs at every minute 15 of every hour of every day.                                   |\n| ,        | Value list separator | `2,10 4,5 * * *` runs at minute 2 and 10 of the 4th and 5th hour of every day.                     |\n| -        | Range of values      | `30 4-6 * * *` runs at minute 30 of the 4th, 5th, and 6th hour.                                    |\n| /        | Step values          | `20/15 * * * *` runs every 15 minutes starting from minute 20 through 59 (minutes 20, 35, and 50). |\n\nThis example triggers the workflow to run at 5:30 AM in the America/New\\_York timezone every Monday through Friday:\n\n```yaml\non:\n  schedule:\n    - cron: '30 5 * * 1-5'\n      timezone: \"America/New_York\"\n```\n\nA single workflow can be triggered by multiple `schedule` events. Access the `schedule` event that triggered the workflow through the `github.event.schedule` context. This example triggers the workflow to run at 5:30 UTC every Monday-Thursday, and 17:30 UTC on Tuesdays and Thursdays, but skips the `Not on Monday or Wednesday` step on Monday and Wednesday.\n\n```yaml\non:\n  schedule:\n    - cron: '30 5 * * 1,3'\n    - cron: '30 5,17 * * 2,4'\n\njobs:\n  test_schedule:\n    runs-on: ubuntu-latest\n    steps:\n      - name: Not on Monday or Wednesday\n        if: github.event.schedule != '30 5 * * 1,3'\n        run: echo \"This step will be skipped on Monday and Wednesday\"\n      - name: Every time\n        run: echo \"This step will always run\"\n```\n\nFor more information about `schedule` events, see [Events that trigger workflows](/en/enterprise-cloud@latest/actions/reference/workflows-and-actions/events-that-trigger-workflows#schedule).\n\n## `on.workflow_call`\n\nUse `on.workflow_call` to define the inputs and outputs for a reusable workflow. You can also map the secrets that are available to the called workflow. For more information on reusable workflows, see [Reuse workflows](/en/enterprise-cloud@latest/actions/using-workflows/reusing-workflows).\n\n## `on.workflow_call.inputs`\n\nWhen using the `workflow_call` keyword, you can optionally specify inputs that are passed to the called workflow from the caller workflow. For more information about the `workflow_call` keyword, see [Events that trigger workflows](/en/enterprise-cloud@latest/actions/using-workflows/events-that-trigger-workflows#workflow-reuse-events).\n\nIn addition to the standard input parameters that are available, `on.workflow_call.inputs` requires a `type` parameter. For more information, see [`on.workflow_call.inputs.<input_id>.type`](#onworkflow_callinputsinput_idtype).\n\nIf a `default` parameter is not set, the default value of the input is `false` for a boolean, `0` for a number, and `\"\"` for a string.\n\nWithin the called workflow, you can use the `inputs` context to refer to an input. For more information, see [Contexts reference](/en/enterprise-cloud@latest/actions/learn-github-actions/contexts#inputs-context).\n\nIf a caller workflow passes an input that is not specified in the called workflow, this results in an error.\n\n### Example of `on.workflow_call.inputs`\n\n```yaml\non:\n  workflow_call:\n    inputs:\n      username:\n        description: 'A username passed from the caller workflow'\n        default: 'john-doe'\n        required: false\n        type: string\n\njobs:\n  print-username:\n    runs-on: ubuntu-latest\n\n    steps:\n      - name: Print the input name to STDOUT\n        run: echo The username is ${{ inputs.username }}\n```\n\nFor more information, see [Reuse workflows](/en/enterprise-cloud@latest/actions/using-workflows/reusing-workflows).\n\n## `on.workflow_call.inputs.<input_id>.type`\n\nRequired if input is defined for the `on.workflow_call` keyword. The value of this parameter is a string specifying the data type of the input. This must be one of: `boolean`, `number`, or `string`.\n\n## `on.workflow_call.outputs`\n\nA map of outputs for a called workflow. Called workflow outputs are available to all downstream jobs in the caller workflow. Each output has an identifier, an optional `description,` and a `value.` The `value` must be set to the value of an output from a job within the called workflow.\n\nIn the example below, two outputs are defined for this reusable workflow: `workflow_output1` and `workflow_output2`. These are mapped to outputs called `job_output1` and `job_output2`, both from a job called `my_job`.\n\n### Example of `on.workflow_call.outputs`\n\n```yaml\non:\n  workflow_call:\n    # Map the workflow outputs to job outputs\n    outputs:\n      workflow_output1:\n        description: \"The first job output\"\n        value: ${{ jobs.my_job.outputs.job_output1 }}\n      workflow_output2:\n        description: \"The second job output\"\n        value: ${{ jobs.my_job.outputs.job_output2 }}\n```\n\nFor information on how to reference a job output, see [`jobs.<job_id>.outputs`](#jobsjob_idoutputs). For more information, see [Reuse workflows](/en/enterprise-cloud@latest/actions/using-workflows/reusing-workflows).\n\n## `on.workflow_call.secrets`\n\nA map of the secrets that can be used in the called workflow.\n\nWithin the called workflow, you can use the `secrets` context to refer to a secret.\n\n> \\[!NOTE]\n> If you are passing the secret to a nested reusable workflow, then you must use [`jobs.<job_id>.secrets`](#jobsjob_idsecrets) again to pass the secret. For more information, see [Reuse workflows](/en/enterprise-cloud@latest/actions/using-workflows/reusing-workflows#passing-secrets-to-nested-workflows).\n\nIf a caller workflow passes a secret that is not specified in the called workflow, this results in an error.\n\n### Example of `on.workflow_call.secrets`\n\n```yaml\non:\n  workflow_call:\n    secrets:\n      access-token:\n        description: 'A token passed from the caller workflow'\n        required: false\n\njobs:\n\n  pass-secret-to-action:\n    runs-on: ubuntu-latest\n    steps:\n    # passing the secret to an action\n      - name: Pass the received secret to an action\n        uses: ./.github/actions/my-action\n        with:\n          token: ${{ secrets.access-token }}\n\n  # passing the secret to a nested reusable workflow\n  pass-secret-to-workflow:\n    uses: ./.github/workflows/my-workflow\n    secrets:\n       token: ${{ secrets.access-token }}\n```\n\n## `on.workflow_call.secrets.<secret_id>`\n\nA string identifier to associate with the secret.\n\n## `on.workflow_call.secrets.<secret_id>.required`\n\nA boolean specifying whether the secret must be supplied.\n\n## `on.workflow_run.<branches|branches-ignore>`\n\nWhen using the `workflow_run` event, you can specify what branches the triggering workflow must run on in order to trigger your workflow.\n\nThe `branches` and `branches-ignore` filters accept glob patterns that use characters like `*`, `**`, `+`, `?`, `!` and others to match more than one branch name. If a name contains any of these characters and you want a literal match, you need to *escape* each of these special characters with `\\`. For more information about glob patterns, see the [Workflow syntax for GitHub Actions](/en/enterprise-cloud@latest/actions/using-workflows/workflow-syntax-for-github-actions#filter-pattern-cheat-sheet).\n\nFor example, a workflow with the following trigger will only run when the workflow named `Build` runs on a branch whose name starts with `releases/`:\n\n```yaml\non:\n  workflow_run:\n    workflows: [\"Build\"]\n    types: [requested]\n    branches:\n      - 'releases/**'\n```\n\nA workflow with the following trigger will only run when the workflow named `Build` runs on a branch that is not named `canary`:\n\n```yaml\non:\n  workflow_run:\n    workflows: [\"Build\"]\n    types: [requested]\n    branches-ignore:\n      - \"canary\"\n```\n\nYou cannot use both the `branches` and `branches-ignore` filters for the same event in a workflow. If you want to both include and exclude branch patterns for a single event, use the `branches` filter along with the `!` character to indicate which branches should be excluded.\n\nThe order that you define patterns matters.\n\n* A matching negative pattern (prefixed with `!`) after a positive match will exclude the branch.\n* A matching positive pattern after a negative match will include the branch again.\n\nFor example, a workflow with the following trigger will run when the workflow named `Build` runs on a branch that is named `releases/10` or `releases/beta/mona` but will not `releases/10-alpha`, `releases/beta/3-alpha`, or `main`. <!-- markdownlint-disable-line outdated-release-phase-terminology -->\n\n```yaml\non:\n  workflow_run:\n    workflows: [\"Build\"]\n    types: [requested]\n    branches:\n      - 'releases/**'\n      - '!releases/**-alpha'\n```\n\n## `on.workflow_dispatch`\n\nWhen using the `workflow_dispatch` event, you can optionally specify inputs that are passed to the workflow.\n\nThis trigger only receives events when the workflow file is on the default branch.\n\n## `on.workflow_dispatch.inputs`\n\nThe triggered workflow receives the inputs in the `inputs` context. For more information, see [Contexts](/en/enterprise-cloud@latest/actions/learn-github-actions/contexts#inputs-context).\n\n> \\[!NOTE]\n>\n> * The workflow will also receive the inputs in the `github.event.inputs` context. The information in the `inputs` context and `github.event.inputs` context is identical except that the `inputs` context preserves Boolean values as Booleans instead of converting them to strings. The `choice` type resolves to a string and is a single selectable option.\n> * The maximum number of top-level properties for `inputs` is 25 .\n> * The maximum payload for `inputs` is 65,535 characters.\n\n### Example of `on.workflow_dispatch.inputs`\n\n```yaml\non:\n  workflow_dispatch:\n    inputs:\n      logLevel:\n        description: 'Log level'\n        required: true\n        default: 'warning'\n        type: choice\n        options:\n          - info\n          - warning\n          - debug\n      print_tags:\n        description: 'True to print to STDOUT'\n        required: true\n        type: boolean\n      tags:\n        description: 'Test scenario tags'\n        required: true\n        type: string\n      environment:\n        description: 'Environment to run tests against'\n        type: environment\n        required: true\n\njobs:\n  print-tag:\n    runs-on: ubuntu-latest\n    if: ${{ inputs.print_tags }} \n    steps:\n      - name: Print the input tag to STDOUT\n        run: echo  The tags are ${{ inputs.tags }} \n```\n\n## `on.workflow_dispatch.inputs.<input_id>.required`\n\nA boolean specifying whether the input must be supplied.\n\n## `on.workflow_dispatch.inputs.<input_id>.type`\n\nThe value of this parameter is a string specifying the data type of the input. This must be one of: `boolean`, `choice`, `number`, `environment` or `string`.\n\n## `permissions`\n\nYou can use `permissions` to 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 [Use GITHUB\\_TOKEN for authentication in workflows](/en/enterprise-cloud@latest/actions/security-guides/automatic-token-authentication#modifying-the-permissions-for-the-github_token).\n\nYou can use `permissions` either as a top-level key, to apply to all jobs in the workflow, or within specific jobs. When you add the `permissions` key within a specific job, all actions and run commands within that job that use the `GITHUB_TOKEN` gain the access rights you specify. For more information, see [`jobs.<job_id>.permissions`](/en/enterprise-cloud@latest/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idpermissions).\n\nOwners of an organization or enterprise can restrict write access for the `GITHUB_TOKEN` at the repository level. For more information, see [Disabling or limiting GitHub Actions for your organization](/en/enterprise-cloud@latest/organizations/managing-organization-settings/disabling-or-limiting-github-actions-for-your-organization#setting-the-permissions-of-the-github_token-for-your-organization) and [Enforcing policies for GitHub Actions in your enterprise](/en/enterprise-cloud@latest/admin/policies/enforcing-policies-for-your-enterprise/enforcing-policies-for-github-actions-in-your-enterprise#enforcing-a-policy-for-workflow-permissions-in-your-enterprise).\n\nWhen a workflow is triggered by the [`pull_request_target`](/en/enterprise-cloud@latest/actions/using-workflows/events-that-trigger-workflows#pull_request_target) event, the `GITHUB_TOKEN` is granted read/write repository permission, even when it is triggered from a public fork. For more information, see [Events that trigger workflows](/en/enterprise-cloud@latest/actions/using-workflows/events-that-trigger-workflows#pull_request_target).\n\nFor each of the available permissions, shown in the table below, you can assign one of the access levels: `read` (if applicable), `write`, or `none`. `write` includes `read`. If you specify the access for any of these permissions, all of those that are not specified are set to `none`.\n\nAvailable permissions and details of what each allows an action to do:\n\n| Permission             | Allows an action using `GITHUB_TOKEN` to                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           |\n| ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |\n| `actions`              | Work with GitHub Actions. For example, `actions: write` permits an action to cancel a workflow run. For more information, see [Permissions required for GitHub Apps](/en/enterprise-cloud@latest/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-actions).                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                     |\n|                        |                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    |\n| `artifact-metadata`    | Work with artifact metadata. For example, `artifact-metadata: write` permits an action to create storage records on behalf of a build artifact. For more information, see [REST API endpoints for artifact metadata](/en/enterprise-cloud@latest/rest/orgs/artifact-metadata?apiVersion=2022-11-28).                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               |\n|                        |                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    |\n|                        |                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    |\n| `attestations`         | Work with artifact attestations. For example, `attestations: write` permits an action to generate an artifact attestation for a build. For more information, see [Using artifact attestations to establish provenance for builds](/en/enterprise-cloud@latest/actions/security-guides/using-artifact-attestations-to-establish-provenance-for-builds)                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                              |\n|                        |                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    |\n| `checks`               | Work with check runs and check suites. For example, `checks: write` permits an action to create a check run. For more information, see [Permissions required for GitHub Apps](/en/enterprise-cloud@latest/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-checks).                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                             |\n| `contents`             | Work with the contents of the repository. For example, `contents: read` permits an action to list the commits, and `contents: write` allows the action to create a release. For more information, see [Permissions required for GitHub Apps](/en/enterprise-cloud@latest/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-contents).                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            |\n| `deployments`          | Work with deployments. For example, `deployments: write` permits an action to create a new deployment. For more information, see [Permissions required for GitHub Apps](/en/enterprise-cloud@latest/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-deployments).                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                              |\n| `discussions`          | Work with GitHub Discussions. For example, `discussions: write` permits an action to close or delete a discussion. For more information, see [Using the GraphQL API for Discussions](/en/enterprise-cloud@latest/graphql/guides/using-the-graphql-api-for-discussions).                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            |\n|                        |                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    |\n| `id-token`             | Fetch an OpenID Connect (OIDC) token. This requires `id-token: write`. For more information, see [OpenID Connect](/en/enterprise-cloud@latest/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#updating-your-actions-for-oidc)                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                  |\n|                        |                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    |\n| `issues`               | Work with issues. For example, `issues: write` permits an action to add a comment to an issue. For more information, see [Permissions required for GitHub Apps](/en/enterprise-cloud@latest/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-issues).                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           |\n|                        |                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    |\n| `models`               | Generate AI inference responses with GitHub Models. For example, `models: read` permits an action to use the GitHub Models inference API. See [Prototyping with AI models](/en/enterprise-cloud@latest/github-models/prototyping-with-ai-models).                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                  |\n|                        |                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    |\n| `packages`             | Work with GitHub Packages. For example, `packages: write` permits an action to upload and publish packages on GitHub Packages. For more information, see [About permissions for GitHub Packages](/en/enterprise-cloud@latest/packages/learn-github-packages/about-permissions-for-github-packages#about-scopes-and-permissions-for-package-registries).                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            |\n| `pages`                | Work with GitHub Pages. For example, `pages: write` permits an action to request a GitHub Pages build. For more information, see [Permissions required for GitHub Apps](/en/enterprise-cloud@latest/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-pages).                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    |\n| `pull-requests`        | Work with pull requests. For example, `pull-requests: write` permits an action to add a label to a pull request. For more information, see [Permissions required for GitHub Apps](/en/enterprise-cloud@latest/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-pull-requests).                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                  |\n|                        |                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    |\n| `security-events`      | Work with GitHub code scanning alerts. For example, `security-events: read` permits an action to list the code scanning alerts for the repository, and `security-events: write` allows an action to update the status of a code scanning alert. For more information, see [Repository permissions for \"Code scanning alerts\"](/en/enterprise-cloud@latest/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-code-scanning-alerts). <br><br> For Dependabot alerts, use the `vulnerability-alerts` permission. Secret scanning alerts cannot be read with this permission and require a GitHub App or a personal access token. For more information, see [Repository permissions for \"Secret scanning alerts\"](/en/enterprise-cloud@latest/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-secret-scanning-alerts) in \"Permissions required for GitHub Apps.\" |\n| `statuses`             | Work with commit statuses. For example, `statuses:read` permits an action to list the commit statuses for a given reference. For more information, see [Permissions required for GitHub Apps](/en/enterprise-cloud@latest/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-commit-statuses).                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    |\n|                        |                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    |\n| `vulnerability-alerts` | Read Dependabot alerts. For example, `vulnerability-alerts: read` permits an action to list Dependabot alerts for the repository. Only `read` and `none` are supported; `write` is not valid. When `write-all` or `read-all` is used, `vulnerability-alerts` is automatically included as `read`. For more information, see [Repository permissions for \"Dependabot alerts\"](/en/enterprise-cloud@latest/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-dependabot-alerts).                                                                                                                                                                                                                                                                                                                                                                                                                                   |\n|                        |                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    |\n\n### Defining access for the `GITHUB_TOKEN` scopes\n\nYou can define the access that the `GITHUB_TOKEN` will permit by specifying `read`, `write`, or `none` as the value of the available permissions within the `permissions` key.\n\n```yaml\npermissions:\n  actions: read|write|none\n  artifact-metadata: read|write|none\n  attestations: read|write|none\n  checks: read|write|none\n  contents: read|write|none\n  deployments: read|write|none\n  id-token: write|none\n  issues: read|write|none\n  models: read|none\n  discussions: read|write|none\n  packages: read|write|none\n  pages: read|write|none\n  pull-requests: read|write|none\n  security-events: read|write|none\n  statuses: read|write|none\n  vulnerability-alerts: read|none\n```\n\nIf you specify the access for any of these permissions, all of those that are not specified are set to `none`.\n\nYou can use the following syntax to define one of `read-all` or `write-all` access for all of the available permissions:\n\n```yaml\npermissions: read-all\n```\n\n```yaml\npermissions: write-all\n```\n\nYou can use the following syntax to disable permissions for all of the available permissions:\n\n```yaml\npermissions: {}\n```\n\n#### Changing the permissions in a forked repository\n\nYou can use the `permissions` key to add and remove read permissions for forked repositories, but typically you can't grant write access. The exception to this behavior is where an admin user has selected the **Send write tokens to workflows from pull requests** option in the GitHub Actions settings. For more information, see [Managing GitHub Actions settings for a repository](/en/enterprise-cloud@latest/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#enabling-workflows-for-private-repository-forks).\n\n## How permissions are calculated for a workflow job\n\nThe permissions for the `GITHUB_TOKEN` are initially set to the default setting for the enterprise, organization, or repository. If the default is set to the restricted permissions at any of these levels then this will apply to the relevant repositories. For example, if you choose the restricted default at the organization level then all repositories in that organization will use the restricted permissions as the default. The permissions are then adjusted based on any configuration within the workflow file, first at the workflow level and then at the job level. Finally, if the workflow was triggered by a pull request event other than `pull_request_target` from a forked repository, and the **Send write tokens to workflows from pull requests** setting is not selected, the permissions are adjusted to change any write permissions to read only.\n\n### Setting the `GITHUB_TOKEN` permissions for all jobs in a workflow\n\nYou can specify `permissions` at the top level of a workflow, so that the setting applies to all jobs in the workflow.\n\n#### Example: Setting the `GITHUB_TOKEN` permissions for an entire workflow\n\nThis example shows permissions being set for the `GITHUB_TOKEN` that will apply to all jobs in the workflow. All permissions are granted read access.\n\n```yaml\nname: \"My workflow\"\n\non: [ push ]\n\npermissions: read-all\n\njobs:\n  ...\n```\n\n### Using the `permissions` key for forked repositories\n\nYou can use the `permissions` key to add and remove `read` permissions for forked repositories, but typically you can't grant `write` access. The exception to this behavior is where an admin user has selected the **Send write tokens to workflows from pull requests** option in the GitHub Actions settings. For more information, see [Managing GitHub Actions settings for a repository](/en/enterprise-cloud@latest/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#enabling-workflows-for-private-repository-forks).\n\n### Permissions for workflow runs triggered by Dependabot\n\nWorkflow runs triggered by Dependabot pull requests run as if they are from a forked repository, and therefore use a read-only `GITHUB_TOKEN`. These workflow runs cannot access any secrets. For information about strategies to keep these workflows secure, see [Secure use reference](/en/enterprise-cloud@latest/actions/security-guides/security-hardening-for-github-actions).\n\n## `env`\n\nA `map` of variables that are available to the steps of all jobs in the workflow. You can also set 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).\n\nVariables in the `env` map cannot be defined in terms of other variables in the map.\n\nWhen more than one environment variable is defined with the same name, GitHub uses the most specific variable. For example, an environment variable defined in a step will override job and workflow environment variables with the same name, while the step executes. An environment variable defined for a job will override a workflow variable with the same name, while the job executes.\n\n### Example of `env`\n\n```yaml\nenv:\n  SERVER: production\n```\n\n## `defaults`\n\nUse `defaults` to create 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`](/en/enterprise-cloud@latest/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_iddefaults).\n\nWhen more than one default setting is defined with the same name, GitHub uses the most specific default setting. For example, a default setting defined in a job will override a default setting that has the same name defined in a workflow.\n\n## `defaults.run`\n\nYou can use `defaults.run` to provide default `shell` and `working-directory` options for all [`run`](/en/enterprise-cloud@latest/actions/using-workflows/workflow-syntax-for-github-actions#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`](/en/enterprise-cloud@latest/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_iddefaultsrun). You cannot use contexts or expressions in this keyword.\n\nWhen more than one default setting is defined with the same name, GitHub uses the most specific default setting. For example, a default setting defined in a job will override a default setting that has the same name defined in a workflow.\n\n### Example: Set the default shell and working directory\n\n```yaml\ndefaults:\n  run:\n    shell: bash\n    working-directory: ./scripts\n```\n\n## `defaults.run.shell`\n\nUse `shell` to define the `shell` for a step. This keyword can reference several contexts. For more information, see [Contexts](/en/enterprise-cloud@latest/actions/learn-github-actions/contexts#context-availability).\n\n| Supported platform | `shell` parameter | Description                                                                                                                                                                                                                                       | Command run internally                          |\n| ------------------ | ----------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------- |\n| Linux / macOS      | unspecified       | The default shell on non-Windows platforms. Note that this runs a different command to when `bash` is specified explicitly. If `bash` is not found in the path, this is treated as `sh`.                                                          | `bash -e {0}`                                   |\n| All                | `bash`            | The default shell on non-Windows platforms with a fallback to `sh`. When specifying a bash shell on Windows, the bash shell included with Git for Windows is used.                                                                                | `bash --noprofile --norc -eo pipefail {0}`      |\n| All                | `pwsh`            | The PowerShell Core. GitHub appends the extension `.ps1` to your script name.                                                                                                                                                                     | `pwsh -command \". '{0}'\"`                       |\n| All                | `python`          | Executes the python command.                                                                                                                                                                                                                      | `python {0}`                                    |\n| Linux / macOS      | `sh`              | The fallback behavior for non-Windows platforms if no shell is provided and `bash` is not found in the path.                                                                                                                                      | `sh -e {0}`                                     |\n| Windows            | `cmd`             | GitHub appends the extension `.cmd` to your script name and substitutes for `{0}`.                                                                                                                                                                | `%ComSpec% /D /E:ON /V:OFF /S /C \"CALL \"{0}\"\"`. |\n| Windows            | `pwsh`            | This is the default shell used on Windows. The PowerShell Core. GitHub 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}'\"`.                      |\n| Windows            | `powershell`      | The PowerShell Desktop. GitHub appends the extension `.ps1` to your script name.                                                                                                                                                                  | `powershell -command \". '{0}'\"`.                |\n\nWhen more than one default setting is defined with the same name, GitHub uses the most specific default setting. For example, a default setting defined in a job will override a default setting that has the same name defined in a workflow.\n\n## `defaults.run.working-directory`\n\nUse `working-directory` to define the working directory for the `shell` for a step. This keyword can reference several contexts. For more information, see [Contexts](/en/enterprise-cloud@latest/actions/learn-github-actions/contexts#context-availability).\n\n> \\[!TIP]\n> Ensure the `working-directory` you assign exists on the runner before you run your shell in it.\n> When more than one default setting is defined with the same name, GitHub uses the most specific default setting. For example, a default setting defined in a job will override a default setting that has the same name defined in a workflow.\n\n## `concurrency`\n\nUse `concurrency` to ensure that only a single job or workflow using the same concurrency group will run at a time. A concurrency group can be any string or expression. The expression can only use [`github`](/en/enterprise-cloud@latest/actions/learn-github-actions/contexts#github-context), [`inputs`](/en/enterprise-cloud@latest/actions/learn-github-actions/contexts#inputs-context) and [`vars`](/en/enterprise-cloud@latest/actions/learn-github-actions/contexts#vars-context) contexts. For more information about expressions, see [Evaluate expressions in workflows and actions](/en/enterprise-cloud@latest/actions/learn-github-actions/expressions).\n\nYou can also specify `concurrency` at the job level. For more information, see [`jobs.<job_id>.concurrency`](/en/enterprise-cloud@latest/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idconcurrency).\n\nThis means that there can be at most one running and one pending job in a concurrency group at any time. When a concurrent job or workflow is queued, if another job or workflow using the same concurrency group in the repository is in progress, the queued job or workflow will be `pending`. Any existing `pending` job or workflow in the same concurrency group, if it exists, will be canceled and the new queued job or workflow will take its place.\n\nTo also cancel any currently running job or workflow in the same concurrency group, specify `cancel-in-progress: true`. To conditionally cancel currently running jobs or workflows in the same concurrency group, you can specify `cancel-in-progress` as an expression with any of the allowed expression contexts.\n\n> \\[!NOTE]\n>\n> * The concurrency group name is case insensitive. For example, `prod` and `Prod` will be treated as the same concurrency group.\n> * Ordering is not guaranteed for jobs or workflow runs using concurrency groups. Jobs or workflow runs in the same concurrency group are handled in an arbitrary order.\n\n### Example: Using concurrency and the default behavior\n\nThe default behavior of GitHub Actions is to allow multiple jobs or workflow runs to run concurrently. The `concurrency` keyword allows you to control the concurrency of workflow runs.\n\nFor example, you can use the `concurrency` keyword immediately after where trigger conditions are defined to limit the concurrency of entire workflow runs for a specific branch:\n\n```yaml\non:\n  push:\n    branches:\n      - main\n\nconcurrency:\n  group: ${{ github.workflow }}-${{ github.ref }}\n  cancel-in-progress: true\n```\n\nYou can also limit the concurrency of jobs within a workflow by using the `concurrency` keyword at the job level:\n\n```yaml\non:\n  push:\n    branches:\n      - main\n\njobs:\n  job-1:\n    runs-on: ubuntu-latest\n    concurrency:\n      group: example-group\n      cancel-in-progress: true\n```\n\n### Example: Concurrency groups\n\nConcurrency groups provide a way to manage and limit the execution of workflow runs or jobs that share the same concurrency key.\n\nThe `concurrency` key is used to group workflows or jobs together into a concurrency group. When you define a `concurrency` key, GitHub Actions ensures that only one workflow or job with that key runs at any given time. If a new workflow run or job starts with the same `concurrency` key, GitHub Actions will cancel any workflow or job already running with that key. The `concurrency` key can be a hard-coded string, or it can be a dynamic expression that includes context variables.\n\nIt is possible to define concurrency conditions in your workflow so that the workflow or job is part of a concurrency group.\n\nThis means that when a workflow run or job starts, GitHub will cancel any workflow runs or jobs that are already in progress in the same concurrency group. This is useful in scenarios where you want to prevent parallel runs for a certain set of a workflows or jobs, such as the ones used for deployments to a staging environment, in order to prevent actions that could cause conflicts or consume more resources than necessary.\n\nIn this example, `job-1` is part of a concurrency group named `staging_environment`. This means that if a new run of `job-1` is triggered, any runs of the same job in the `staging_environment` concurrency group that are already in progress will be cancelled.\n\n```yaml\njobs:\n  job-1:\n    runs-on: ubuntu-latest\n    concurrency:\n      group: staging_environment\n      cancel-in-progress: true\n```\n\nAlternatively, using a dynamic expression such as `concurrency: ci-${{ github.ref }}` in your workflow means that the workflow or job would be part of a concurrency group named `ci-` followed by the reference of the branch or tag that triggered the workflow. In this example, if a new commit is pushed to the main branch while a previous run is still in progress, the previous run will be cancelled and the new one will start:\n\n```yaml\non:\n  push:\n    branches:\n      - main\n\nconcurrency:\n  group: ci-${{ github.ref }}\n  cancel-in-progress: true\n```\n\n### Example: Using concurrency to cancel any in-progress job or run\n\nTo use concurrency to cancel any in-progress job or run in GitHub Actions, you can use the `concurrency` key with the `cancel-in-progress` option set to `true`:\n\n```yaml\nconcurrency:\n  group: ${{ github.ref }}\n  cancel-in-progress: true\n```\n\nNote that in this example, without defining a particular concurrency group, GitHub Actions will cancel *any* in-progress run of the job or workflow.\n\n### Example: Using a fallback value\n\nIf you build the group name with a property that is only defined for specific events, you can use a fallback value. For example, `github.head_ref` is only defined on `pull_request` events. If your workflow responds to other events in addition to `pull_request` events, you will need to provide a fallback to avoid a syntax error. The following concurrency group cancels in-progress jobs or runs on `pull_request` events only; if `github.head_ref` is undefined, the concurrency group will fallback to the run ID, which is guaranteed to be both unique and defined for the run.\n\n```yaml\nconcurrency:\n  group: ${{ github.head_ref || github.run_id }}\n  cancel-in-progress: true\n```\n\n### Example: Only cancel in-progress jobs or runs for the current workflow\n\nIf you have multiple workflows in the same repository, concurrency group names must be unique across workflows to avoid canceling in-progress jobs or runs from other workflows. Otherwise, any previously in-progress or pending job will be canceled, regardless of the workflow.\n\nTo only cancel in-progress runs of the same workflow, you can use the `github.workflow` property to build the concurrency group:\n\n```yaml\nconcurrency:\n  group: ${{ github.workflow }}-${{ github.ref }}\n  cancel-in-progress: true\n```\n\n### Example: Only cancel in-progress jobs on specific branches\n\nIf you would like to cancel in-progress jobs on certain branches but not on others, you can use conditional expressions with `cancel-in-progress`. For example, you can do this if you would like to cancel in-progress jobs on development branches but not on release branches.\n\nTo only cancel in-progress runs of the same workflow when not running on a release branch, you can set `cancel-in-progress` to an expression similar to the following:\n\n```yaml\nconcurrency:\n  group: ${{ github.workflow }}-${{ github.ref }}\n  cancel-in-progress: ${{ !contains(github.ref, 'release/')}}\n```\n\nIn this example, multiple pushes to a `release/1.2.3` branch would not cancel in-progress runs. Pushes to another branch, such as `main`, would cancel in-progress runs.\n\n## `jobs`\n\nA workflow run is made up of one or more `jobs`, which run in parallel by default. To run jobs sequentially, you can define dependencies on other jobs using the `jobs.<job_id>.needs` keyword.\n\nEach job runs in a runner environment specified by `runs-on`.\n\nYou can run an unlimited number of jobs as long as you are within the workflow usage limits. For more information, see [Billing and usage](/en/enterprise-cloud@latest/actions/learn-github-actions/usage-limits-billing-and-administration) for GitHub-hosted runners and [Actions limits](/en/enterprise-cloud@latest/actions/hosting-your-own-runners/managing-self-hosted-runners/usage-limits-for-self-hosted-runners) for self-hosted runner usage limits.\n\nIf you need to find the unique identifier of a job running in a workflow run, you can use the GitHub API. For more information, see [REST API endpoints for GitHub Actions](/en/enterprise-cloud@latest/rest/actions#workflow-jobs).\n\n## `jobs.<job_id>`\n\nUse `jobs.<job_id>` to give your job a unique identifier. 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 `_`.\n\n### Example: Creating jobs\n\nIn this example, two jobs have been created, and their `job_id` values are `my_first_job` and `my_second_job`.\n\n```yaml\njobs:\n  my_first_job:\n    name: My first job\n  my_second_job:\n    name: My second job\n```\n\n## `jobs.<job_id>.name`\n\nUse `jobs.<job_id>.name` to set a name for the job, which is displayed in the GitHub UI.\n\n## `jobs.<job_id>.permissions`\n\nFor a specific job, you can use `jobs.<job_id>.permissions` to 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 [Use GITHUB\\_TOKEN for authentication in workflows](/en/enterprise-cloud@latest/actions/security-guides/automatic-token-authentication#modifying-the-permissions-for-the-github_token).\n\nBy specifying the permission within a job definition, you can configure a different set of permissions for the `GITHUB_TOKEN` for each job, if required. Alternatively, you can specify the permissions for all jobs in the workflow. For information on defining permissions at the workflow level, see [`permissions`](/en/enterprise-cloud@latest/actions/using-workflows/workflow-syntax-for-github-actions#permissions).\n\nFor each of the available permissions, shown in the table below, you can assign one of the access levels: `read` (if applicable), `write`, or `none`. `write` includes `read`. If you specify the access for any of these permissions, all of those that are not specified are set to `none`.\n\nAvailable permissions and details of what each allows an action to do:\n\n| Permission             | Allows an action using `GITHUB_TOKEN` to                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           |\n| ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |\n| `actions`              | Work with GitHub Actions. For example, `actions: write` permits an action to cancel a workflow run. For more information, see [Permissions required for GitHub Apps](/en/enterprise-cloud@latest/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-actions).                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                     |\n|                        |                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    |\n| `artifact-metadata`    | Work with artifact metadata. For example, `artifact-metadata: write` permits an action to create storage records on behalf of a build artifact. For more information, see [REST API endpoints for artifact metadata](/en/enterprise-cloud@latest/rest/orgs/artifact-metadata?apiVersion=2022-11-28).                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               |\n|                        |                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    |\n|                        |                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    |\n| `attestations`         | Work with artifact attestations. For example, `attestations: write` permits an action to generate an artifact attestation for a build. For more information, see [Using artifact attestations to establish provenance for builds](/en/enterprise-cloud@latest/actions/security-guides/using-artifact-attestations-to-establish-provenance-for-builds)                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                              |\n|                        |                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    |\n| `checks`               | Work with check runs and check suites. For example, `checks: write` permits an action to create a check run. For more information, see [Permissions required for GitHub Apps](/en/enterprise-cloud@latest/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-checks).                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                             |\n| `contents`             | Work with the contents of the repository. For example, `contents: read` permits an action to list the commits, and `contents: write` allows the action to create a release. For more information, see [Permissions required for GitHub Apps](/en/enterprise-cloud@latest/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-contents).                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            |\n| `deployments`          | Work with deployments. For example, `deployments: write` permits an action to create a new deployment. For more information, see [Permissions required for GitHub Apps](/en/enterprise-cloud@latest/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-deployments).                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                              |\n| `discussions`          | Work with GitHub Discussions. For example, `discussions: write` permits an action to close or delete a discussion. For more information, see [Using the GraphQL API for Discussions](/en/enterprise-cloud@latest/graphql/guides/using-the-graphql-api-for-discussions).                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            |\n|                        |                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    |\n| `id-token`             | Fetch an OpenID Connect (OIDC) token. This requires `id-token: write`. For more information, see [OpenID Connect](/en/enterprise-cloud@latest/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#updating-your-actions-for-oidc)                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                  |\n|                        |                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    |\n| `issues`               | Work with issues. For example, `issues: write` permits an action to add a comment to an issue. For more information, see [Permissions required for GitHub Apps](/en/enterprise-cloud@latest/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-issues).                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           |\n|                        |                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    |\n| `models`               | Generate AI inference responses with GitHub Models. For example, `models: read` permits an action to use the GitHub Models inference API. See [Prototyping with AI models](/en/enterprise-cloud@latest/github-models/prototyping-with-ai-models).                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                  |\n|                        |                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    |\n| `packages`             | Work with GitHub Packages. For example, `packages: write` permits an action to upload and publish packages on GitHub Packages. For more information, see [About permissions for GitHub Packages](/en/enterprise-cloud@latest/packages/learn-github-packages/about-permissions-for-github-packages#about-scopes-and-permissions-for-package-registries).                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            |\n| `pages`                | Work with GitHub Pages. For example, `pages: write` permits an action to request a GitHub Pages build. For more information, see [Permissions required for GitHub Apps](/en/enterprise-cloud@latest/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-pages).                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    |\n| `pull-requests`        | Work with pull requests. For example, `pull-requests: write` permits an action to add a label to a pull request. For more information, see [Permissions required for GitHub Apps](/en/enterprise-cloud@latest/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-pull-requests).                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                  |\n|                        |                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    |\n| `security-events`      | Work with GitHub code scanning alerts. For example, `security-events: read` permits an action to list the code scanning alerts for the repository, and `security-events: write` allows an action to update the status of a code scanning alert. For more information, see [Repository permissions for \"Code scanning alerts\"](/en/enterprise-cloud@latest/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-code-scanning-alerts). <br><br> For Dependabot alerts, use the `vulnerability-alerts` permission. Secret scanning alerts cannot be read with this permission and require a GitHub App or a personal access token. For more information, see [Repository permissions for \"Secret scanning alerts\"](/en/enterprise-cloud@latest/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-secret-scanning-alerts) in \"Permissions required for GitHub Apps.\" |\n| `statuses`             | Work with commit statuses. For example, `statuses:read` permits an action to list the commit statuses for a given reference. For more information, see [Permissions required for GitHub Apps](/en/enterprise-cloud@latest/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-commit-statuses).                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    |\n|                        |                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    |\n| `vulnerability-alerts` | Read Dependabot alerts. For example, `vulnerability-alerts: read` permits an action to list Dependabot alerts for the repository. Only `read` and `none` are supported; `write` is not valid. When `write-all` or `read-all` is used, `vulnerability-alerts` is automatically included as `read`. For more information, see [Repository permissions for \"Dependabot alerts\"](/en/enterprise-cloud@latest/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-dependabot-alerts).                                                                                                                                                                                                                                                                                                                                                                                                                                   |\n|                        |                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    |\n\n### Defining access for the `GITHUB_TOKEN` scopes\n\nYou can define the access that the `GITHUB_TOKEN` will permit by specifying `read`, `write`, or `none` as the value of the available permissions within the `permissions` key.\n\n```yaml\npermissions:\n  actions: read|write|none\n  artifact-metadata: read|write|none\n  attestations: read|write|none\n  checks: read|write|none\n  contents: read|write|none\n  deployments: read|write|none\n  id-token: write|none\n  issues: read|write|none\n  models: read|none\n  discussions: read|write|none\n  packages: read|write|none\n  pages: read|write|none\n  pull-requests: read|write|none\n  security-events: read|write|none\n  statuses: read|write|none\n  vulnerability-alerts: read|none\n```\n\nIf you specify the access for any of these permissions, all of those that are not specified are set to `none`.\n\nYou can use the following syntax to define one of `read-all` or `write-all` access for all of the available permissions:\n\n```yaml\npermissions: read-all\n```\n\n```yaml\npermissions: write-all\n```\n\nYou can use the following syntax to disable permissions for all of the available permissions:\n\n```yaml\npermissions: {}\n```\n\n#### Changing the permissions in a forked repository\n\nYou can use the `permissions` key to add and remove read permissions for forked repositories, but typically you can't grant write access. The exception to this behavior is where an admin user has selected the **Send write tokens to workflows from pull requests** option in the GitHub Actions settings. For more information, see [Managing GitHub Actions settings for a repository](/en/enterprise-cloud@latest/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#enabling-workflows-for-private-repository-forks).\n\n#### Example: Setting the `GITHUB_TOKEN` permissions for one job in a workflow\n\nThis 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` permissions. All other permissions will have no access.\n\n```yaml\njobs:\n  stale:\n    runs-on: ubuntu-latest\n\n    permissions:\n      issues: write\n      pull-requests: write\n\n    steps:\n      - uses: actions/stale@v10\n```\n\n## `jobs.<job_id>.needs`\n\nUse `jobs.<job_id>.needs` to identify any jobs that must complete successfully before this job will run. It can be a string or array of strings. If a job fails or is skipped, all jobs that need it are skipped unless the jobs use a conditional expression that causes the job to continue. If a run contains a series of jobs that need each other, a failure or skip applies to all jobs in the dependency chain from the point of failure or skip onwards. If you would like a job to run even if a job it is dependent on did not succeed, use the `always()` conditional expression in `jobs.<job_id>.if`.\n\n### Example: Requiring successful dependent jobs\n\n```yaml\njobs:\n  job1:\n  job2:\n    needs: job1\n  job3:\n    needs: [job1, job2]\n```\n\nIn this example, `job1` must complete successfully before `job2` begins, and `job3` waits for both `job1` and `job2` to complete.\n\nThe jobs in this example run sequentially:\n\n1. `job1`\n2. `job2`\n3. `job3`\n\n### Example: Not requiring successful dependent jobs\n\n```yaml\njobs:\n  job1:\n  job2:\n    needs: job1\n  job3:\n    if: ${{ always() }}\n    needs: [job1, job2]\n```\n\nIn 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 [Evaluate expressions in workflows and actions](/en/enterprise-cloud@latest/actions/learn-github-actions/expressions#status-check-functions).\n\n## `jobs.<job_id>.if`\n\nYou can use the `jobs.<job_id>.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. For more information on which contexts are supported in this key, see [Contexts reference](/en/enterprise-cloud@latest/actions/learn-github-actions/contexts#context-availability).\n\n> \\[!NOTE]\n> The `jobs.<job_id>.if` condition is evaluated before [`jobs.<job_id>.strategy.matrix`](/en/enterprise-cloud@latest/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstrategymatrix) is applied.\n\nWhen you use expressions in an `if` conditional, you can, optionally, omit the `${{ }}` expression syntax because GitHub Actions automatically evaluates the `if` conditional as an expression. However, this exception does not apply everywhere.\n\nYou must always use the `${{ }}` expression syntax or escape with `''`, `\"\"`, or `()` when the expression starts with `!`, since `!` is reserved notation in YAML format. For example:\n\n```yaml\nif: ${{ ! startsWith(github.ref, 'refs/tags/') }}\n```\n\nFor more information, see [Evaluate expressions in workflows and actions](/en/enterprise-cloud@latest/actions/learn-github-actions/expressions).\n\n### Example: Only run job for specific repository\n\nThis example uses `if` to control when the `production-deploy` job can run. It will only run if the repository is named `octo-repo-prod` and is within the `octo-org` organization. Otherwise, the job will be marked as *skipped*.\n\n```yaml copy\nname: example-workflow\non: [push]\njobs:\n  production-deploy:\n    if: github.repository == 'octo-org/octo-repo-prod'\n    runs-on: ubuntu-latest\n    steps:\n      - uses: actions/checkout@v6\n      - uses: actions/setup-node@v4\n        with:\n          node-version: '14'\n      - run: npm install -g bats\n```\n\n## `jobs.<job_id>.runs-on`\n\nUse `jobs.<job_id>.runs-on` to define the type of machine to run the job on.\n\n* The destination machine can be either a [GitHub-hosted runner](#choosing-github-hosted-runners), [larger runner](#choosing-runners-in-a-group), or a [self-hosted runner](#choosing-self-hosted-runners).\n\n- You can target runners based on the labels assigned to them, or their group membership, or a combination of these.\n\n- You can provide `runs-on` as:\n  * A single string\n  * A single variable containing a string\n  * An array of strings, variables containing strings, or a combination of both\n  * A `key: value` pair using the `group` or `labels` keys\n\n- If you specify an array of strings or variables, your workflow will execute on any runner that matches all of the specified `runs-on` values. For example, here the job will only run on a self-hosted runner that has the labels `linux`, `x64`, and `gpu`:\n\n  ```yaml\n  runs-on: [self-hosted, linux, x64, gpu]\n  ```\n\n  For more information, see [Choosing self-hosted runners](#choosing-self-hosted-runners).\n\n- You can mix strings and variables in an array. For example:\n\n  ```yaml\n  on:\n    workflow_dispatch:\n      inputs:\n        chosen-os:\n          required: true\n          type: choice\n          options:\n          - Ubuntu\n          - macOS\n\n  jobs:\n    test:\n      runs-on: [self-hosted, \"${{ inputs.chosen-os }}\"]\n      steps:\n      - run: echo Hello world!\n  ```\n\n- If you would like to run your workflow on multiple machines, use [`jobs.<job_id>.strategy`](/en/enterprise-cloud@latest/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstrategy).\n\n> \\[!NOTE]\n> Quotation marks are not required around simple strings like `self-hosted`, but they are required for expressions like  `\"${{ inputs.chosen-os }}\"`.\n\n### Choosing GitHub-hosted runners\n\nIf you use a GitHub-hosted runner, each job runs in a fresh instance of a runner image specified by `runs-on`.\n\nThe value for runs-on, when you are using a GitHub-hosted runner, is a runner label or the name of a runner group. The labels for the standard GitHub-hosted runners are shown in the following tables.\n\nFor more information, see [GitHub-hosted runners](/en/enterprise-cloud@latest/actions/using-github-hosted-runners/about-github-hosted-runners/about-github-hosted-runners).\n\n### Standard GitHub-hosted runners for public repositories\n\nFor public repositories, jobs using the workflow labels shown in the table below will run with the associated specifications. With the exception of single-CPU runners, each GitHub-hosted runner is a new virtual machine (VM) hosted by GitHub. Single-CPU runners are hosted in a container on a shared VM—see [GitHub-hosted runners reference](/en/enterprise-cloud@latest/actions/reference/runners/github-hosted-runners#single-cpu-runners). Use of the standard GitHub-hosted runners is free and unlimited on public repositories.\n\n<table style=\"width:100%\">\n  <thead>\n    <tr>\n      <th scope=\"col\"><b>Virtual machine / container</b></th>\n      <th scope=\"col\"><b>Processor (CPU)</b></th>\n      <th scope=\"col\"><b>Memory (RAM)</b></th>\n      <th scope=\"col\"><b>Storage (SSD)</b></th>\n      <th scope=\"col\"><b>Architecture</b></th>\n      <th scope=\"col\"><b>Workflow label</b></th>\n    </tr>\n  </thead>\n  <tbody>\n    <tr>\n          <td>Linux</td>\n          <td>1</td>\n          <td>5 GB</td>\n          <td>14 GB</td>\n          <td> x64 </td>\n          <td>\n            <code><a href=\"https://github.com/actions/runner-images/blob/main/images/ubuntu-slim/ubuntu-slim-Readme.md\">ubuntu-slim</a></code>\n          </td>\n        </tr>\n    <tr>\n      <td>Linux</td>\n      <td>4</td>\n      <td>16 GB</td>\n      <td>14 GB</td>\n      <td> x64 </td>\n      <td>\n        <code><a href=\"https://github.com/actions/runner-images/blob/main/images/ubuntu/Ubuntu2404-Readme.md\">ubuntu-latest</a></code>,\n        <code><a href=\"https://github.com/actions/runner-images/blob/main/images/ubuntu/Ubuntu2404-Readme.md\">ubuntu-24.04</a></code>,\n        <code><a href=\"https://github.com/actions/runner-images/blob/main/images/ubuntu/Ubuntu2204-Readme.md\">ubuntu-22.04</a></code>\n      </td>\n    </tr>\n    <tr>\n      <td>Windows</td>\n      <td>4</td>\n      <td>16 GB</td>\n      <td>14 GB</td>\n      <td> x64 </td>\n      <td>\n        <code><a href=\"https://github.com/actions/runner-images/blob/main/images/windows/Windows2025-Readme.md\">windows-latest</a></code>,\n         <code><a href=\"https://github.com/actions/runner-images/blob/main/images/windows/Windows2025-Readme.md\">windows-2025</a></code>,\n        <code><a href=\"https://github.com/actions/runner-images/blob/main/images/windows/Windows2025-VS2026-Readme.md\">windows-2025-vs2026</a></code> (public preview),\n        <code><a href=\"https://github.com/actions/runner-images/blob/main/images/windows/Windows2022-Readme.md\">windows-2022</a></code>\n      </td>\n    </tr>\n    <tr>\n      <td>Linux</td>\n      <td>4</td>\n      <td>16 GB</td>\n      <td>14 GB</td>\n      <td> arm64 </td>\n      <td>\n        <code><a href=\"https://github.com/actions/partner-runner-images/blob/main/images/arm-ubuntu-24-image.md\">ubuntu-24.04-arm</a></code>,\n        <code><a href=\"https://github.com/actions/partner-runner-images/blob/main/images/arm-ubuntu-22-image.md\">ubuntu-22.04-arm</a></code>\n      </td>\n    </tr>\n    <tr>\n      <td>Windows</td>\n      <td>4</td>\n      <td>16 GB</td>\n      <td>14 GB</td>\n      <td>arm64</td>\n      <td>\n        <code><a href=\"https://github.com/actions/partner-runner-images/blob/main/images/arm-windows-11-image.md\">windows-11-arm</a></code>\n      </td>\n    </tr>\n    <tr>\n      <td>macOS</td>\n      <td>4</td>\n      <td>14 GB</td>\n      <td>14 GB</td>\n      <td> Intel </td>\n      <td>\n        <code><a href=\"https://github.com/actions/runner-images/blob/main/images/macos/macos-15-Readme.md\">macos-15-intel</a></code>,\n        <code><a href=\"https://github.com/actions/runner-images/blob/main/images/macos/macos-26-Readme.md\">macos-26-intel</a></code>\n      </td>\n    </tr>\n    <tr>\n      <td>macOS</td>\n      <td>3 (M1)</td>\n      <td>7 GB</td>\n      <td>14 GB</td>\n      <td> arm64 </td>\n      <td>\n        <code><a href=\"https://github.com/actions/runner-images/blob/main/images/macos/macos-15-arm64-Readme.md\">macos-latest</a></code>,\n        <code><a href=\"https://github.com/actions/runner-images/blob/main/images/macos/macos-14-arm64-Readme.md\">macos-14</a></code>,\n        <code><a href=\"https://github.com/actions/runner-images/blob/main/images/macos/macos-15-arm64-Readme.md\">macos-15</a></code>,\n        <code><a href=\"https://github.com/actions/runner-images/blob/main/images/macos/macos-26-arm64-Readme.md\">macos-26</a></code>\n      </td>\n    </tr>\n  </tbody>\n\n</table>\n\n### Standard GitHub-hosted runners for internal and private repositories\n\nFor internal and private repositories, jobs using the workflow labels shown in the table below will run on virtual machines with the associated specifications. These runners use your GitHub account's allotment of free minutes, and are then charged at the per minute rates. See [Actions runner pricing](/en/enterprise-cloud@latest/billing/reference/actions-minute-multipliers).\n\n<table style=\"width:100%\">\n  <thead>\n    <tr>\n      <th scope=\"col\"><b>Virtual Machine</b></th>\n      <th scope=\"col\"><b>Processor (CPU)</b></th>\n      <th scope=\"col\"><b>Memory (RAM)</b></th>\n      <th scope=\"col\"><b>Storage (SSD)</b></th>\n      <th scope=\"col\"><b>Architecture</b></th>\n      <th scope=\"col\"><b>Workflow label</b></th>\n    </tr>\n  </thead>\n  <tbody>\n    <tr>\n          <td>Linux</td>\n          <td>1</td>\n          <td>5 GB</td>\n          <td>14 GB</td>\n          <td> x64 </td>\n          <td>\n            <code><a href=\"https://github.com/actions/runner-images/blob/main/images/ubuntu-slim/ubuntu-slim-Readme.md\">ubuntu-slim</a></code>\n          </td>\n        </tr>\n    <tr>\n      <td>Linux</td>\n      <td>2</td>\n      <td>8 GB</td>\n      <td>14 GB</td>\n      <td> x64 </td>\n      <td>\n        <code><a href=\"https://github.com/actions/runner-images/blob/main/images/ubuntu/Ubuntu2404-Readme.md\">ubuntu-latest</a></code>,\n        <code><a href=\"https://github.com/actions/runner-images/blob/main/images/ubuntu/Ubuntu2404-Readme.md\">ubuntu-24.04</a></code>,\n        <code><a href=\"https://github.com/actions/runner-images/blob/main/images/ubuntu/Ubuntu2204-Readme.md\">ubuntu-22.04</a></code>\n      </td>\n    </tr>\n    <tr>\n      <td>Windows</td>\n      <td>2</td>\n      <td>8 GB</td>\n      <td>14 GB</td>\n      <td> x64 </td>\n      <td>\n        <code><a href=\"https://github.com/actions/runner-images/blob/main/images/windows/Windows2025-Readme.md\">windows-latest</a></code>,\n        <code><a href=\"https://github.com/actions/runner-images/blob/main/images/windows/Windows2025-Readme.md\">windows-2025</a></code>,\n        <code><a href=\"https://github.com/actions/runner-images/blob/main/images/windows/Windows2022-Readme.md\">windows-2022</a></code>\n      </td>\n    </tr>\n    <tr>\n      <td>Linux</td>\n      <td>2</td>\n      <td>8 GB</td>\n      <td>14 GB</td>\n      <td> arm64 </td>\n      <td>\n        <code><a href=\"https://github.com/actions/partner-runner-images/blob/main/images/arm-ubuntu-24-image.md\">ubuntu-24.04-arm</a></code>,\n        <code><a href=\"https://github.com/actions/partner-runner-images/blob/main/images/arm-ubuntu-22-image.md\">ubuntu-22.04-arm</a></code>\n      </td>\n    </tr>\n    <tr>\n      <td>Windows</td>\n      <td>2</td>\n      <td>8 GB</td>\n      <td>14 GB</td>\n      <td> arm64 </td>\n      <td>\n        <code><a href=\"https://github.com/actions/partner-runner-images/blob/main/images/arm-windows-11-image.md\">windows-11-arm</a></code>\n      </td>\n    </tr>\n    <tr>\n      <td>macOS</td>\n      <td>4</td>\n      <td>14 GB</td>\n      <td>14 GB</td>\n      <td> Intel </td>\n      <td>\n        <code><a href=\"https://github.com/actions/runner-images/blob/main/images/macos/macos-15-Readme.md\">macos-15-intel</a></code>,\n        <code><a href=\"https://github.com/actions/runner-images/blob/main/images/macos/macos-26-Readme.md\">macos-26-intel</a></code>\n      </td>\n    </tr>\n    <tr>\n      <td>macOS</td>\n      <td>3 (M1)</td>\n      <td>7 GB</td>\n      <td>14 GB</td>\n      <td> arm64 </td>\n      <td>\n        <code><a href=\"https://github.com/actions/runner-images/blob/main/images/macos/macos-15-arm64-Readme.md\">macos-latest</a></code>,\n        <code><a href=\"https://github.com/actions/runner-images/blob/main/images/macos/macos-14-arm64-Readme.md\">macos-14</a></code>,\n        <code><a href=\"https://github.com/actions/runner-images/blob/main/images/macos/macos-15-arm64-Readme.md\">macos-15</a></code>,\n        <code><a href=\"https://github.com/actions/runner-images/blob/main/images/macos/macos-26-arm64-Readme.md\">macos-26</a></code>\n      </td>\n    </tr>\n  </tbody>\n</table>\n\n> \\[!NOTE] macOS runners are not available on subdomains of GHE.com, such as `octocorp.ghe.com`.\n\nIn addition to the standard GitHub-hosted runners, GitHub offers customers on GitHub Team and GitHub Enterprise Cloud plans a range of managed virtual machines with advanced features - for example, more cores and disk space, GPU-powered machines, and ARM-powered machines. For more information, see [Larger runners](/en/enterprise-cloud@latest/actions/using-github-hosted-runners/about-larger-runners/about-larger-runners).\n\n> \\[!NOTE]\n> The `-latest` runner images are the latest stable images that GitHub provides, and might not be the most recent version of the operating system available from the operating system vendor.\n\n> \\[!WARNING]\n> Beta and Deprecated Images are provided \"as-is\", \"with all faults\" and \"as available\" and are excluded from the service level agreement and warranty. Beta Images may not be covered by customer support.\n\n#### Example: Specifying an operating system\n\n```yaml\nruns-on: ubuntu-latest\n```\n\nFor more information, see [GitHub-hosted runners](/en/enterprise-cloud@latest/actions/using-github-hosted-runners/about-github-hosted-runners).\n\n### Choosing self-hosted runners\n\nTo specify a self-hosted runner for your job, configure `runs-on` in your workflow file with self-hosted runner labels.\n\nSelf-hosted runners may have the `self-hosted` label. When setting up a self-hosted runner, by default we will include the label `self-hosted`. You may pass in the `--no-default-labels` flag to prevent the self-hosted label from being applied. Labels can be used to create targeting options for runners, such as operating system or architecture, we recommend providing an array of labels that begins with `self-hosted` (this must be listed first) and then includes additional labels as needed. When you specify an array of labels, jobs will be queued on runners that have all the labels that you specify.\n\n> \\[!NOTE] Actions Runner Controller does not support the `self-hosted` label.\n\n#### Example: Using labels for runner selection\n\n```yaml\nruns-on: [self-hosted, linux]\n```\n\nFor more information, see [Self-hosted runners](/en/enterprise-cloud@latest/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners) and [Using self-hosted runners in a workflow](/en/enterprise-cloud@latest/actions/hosting-your-own-runners/managing-self-hosted-runners/using-self-hosted-runners-in-a-workflow).\n\n### Choosing runners in a group\n\nYou can use `runs-on` to target runner groups, so that the job will execute on any runner that is a member of that group. For more granular control, you can also combine runner groups with labels.\n\nRunner groups can only have [larger runners](/en/enterprise-cloud@latest/actions/using-github-hosted-runners/using-larger-runners/about-larger-runners) or [self-hosted runners](/en/enterprise-cloud@latest/actions/how-tos/managing-self-hosted-runners) as members.\n\n#### Example: Using groups to control where jobs are run\n\nIn this example, Ubuntu runners have been added to a group called `ubuntu-runners`. The `runs-on` key sends the job to any available runner in the `ubuntu-runners` group:\n\n```yaml\nname: learn-github-actions\non: [push]\njobs:\n  check-bats-version:\n    runs-on: \n      group: ubuntu-runners\n    steps:\n      - uses: actions/checkout@v6\n      - uses: actions/setup-node@v4\n        with:\n          node-version: '14'\n      - run: npm install -g bats\n      - run: bats -v\n```\n\n#### Example: Combining groups and labels\n\nWhen you combine groups and labels, the runner must meet both requirements to be eligible to run the job.\n\nIn this example, a runner group called `ubuntu-runners` is populated with Ubuntu runners, which have also been assigned the label `ubuntu-24.04-16core`. The `runs-on` key combines `group` and `labels` so that the job is routed to any available runner within the group that also has a matching label:\n\n```yaml\nname: learn-github-actions\non: [push]\njobs:\n  check-bats-version:\n    runs-on:\n      group: ubuntu-runners\n      labels: ubuntu-24.04-16core\n    steps:\n      - uses: actions/checkout@v6\n      - uses: actions/setup-node@v4\n        with:\n          node-version: '14'\n      - run: npm install -g bats\n      - run: bats -v\n```\n\n#### Example: using prefixes to differentiate runner groups\n\nFor example, if you have a runner group named `my-group` in the organization and another named `my-group` in the enterprise, you can update your workflow file to use `org/my-group` or `ent/my-group` to differentiate between the two.\n\nUsing `org/`:\n\n```yaml\nruns-on:\n  group: org/my-group\n  labels: [ self-hosted, label-1 ]\n```\n\nUsing `ent/`:\n\n```yaml\nruns-on:\n  group: ent/my-group\n  labels: [ self-hosted, label-1 ]\n```\n\n## `jobs.<job_id>.snapshot`\n\nYou can use `jobs.<job_id>.snapshot` to generate a custom image.\n\nAdd the snapshot keyword to the job, using either the string syntax or mapping syntax as shown in [Generating a custom image](/en/enterprise-cloud@latest/actions/how-tos/manage-runners/larger-runners/use-custom-images#generating-a-custom-image).\n\nEach job that includes the snapshot keyword creates a separate image. To generate only one image or image version, include all workflow steps in a single job. Each successful run of a job that includes the snapshot keyword creates a new version of that image.\n\nFor more information, see [Using custom images](/en/enterprise-cloud@latest/actions/how-tos/manage-runners/larger-runners/use-custom-images).\n\n## `jobs.<job_id>.environment`\n\nUse `jobs.<job_id>.environment` to define the environment that the job references.\n\nYou 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 [REST API endpoints for repositories](/en/enterprise-cloud@latest/rest/repos#deployments).\n\n> \\[!NOTE]\n> All deployment protection rules must pass before a job referencing the environment is sent to a runner. For more information, see [Managing environments for deployment](/en/enterprise-cloud@latest/actions/deployment/targeting-different-environments/managing-environments-for-deployment).\n\n### Example: Using a single environment name\n\n```yaml\nenvironment: staging_environment\n```\n\n### Example: Using environment name and URL\n\n```yaml\nenvironment:\n  name: production_environment\n  url: https://github.com\n```\n\nThe value of `url` can be an expression. Allowed expression contexts: [`github`](/en/enterprise-cloud@latest/actions/learn-github-actions/contexts#github-context), [`inputs`](/en/enterprise-cloud@latest/actions/learn-github-actions/contexts#inputs-context), [`vars`](/en/enterprise-cloud@latest/actions/learn-github-actions/contexts#vars-context), [`needs`](/en/enterprise-cloud@latest/actions/learn-github-actions/contexts#needs-context), [`strategy`](/en/enterprise-cloud@latest/actions/learn-github-actions/contexts#strategy-context), [`matrix`](/en/enterprise-cloud@latest/actions/learn-github-actions/contexts#matrix-context), [`job`](/en/enterprise-cloud@latest/actions/learn-github-actions/contexts#job-context), [`runner`](/en/enterprise-cloud@latest/actions/learn-github-actions/contexts#runner-context), [`env`](/en/enterprise-cloud@latest/actions/learn-github-actions/contexts#env-context), and [`steps`](/en/enterprise-cloud@latest/actions/learn-github-actions/contexts#steps-context). For more information about expressions, see [Evaluate expressions in workflows and actions](/en/enterprise-cloud@latest/actions/learn-github-actions/expressions).\n\n### Example: Using output as URL\n\n```yaml\nenvironment:\n  name: production_environment\n  url: ${{ steps.step_id.outputs.url_output }}\n```\n\nThe value of `name` can be an expression. Allowed expression contexts: [`github`](/en/enterprise-cloud@latest/actions/learn-github-actions/contexts#github-context), [`inputs`](/en/enterprise-cloud@latest/actions/learn-github-actions/contexts#inputs-context), [`vars`](/en/enterprise-cloud@latest/actions/learn-github-actions/contexts#vars-context), [`needs`](/en/enterprise-cloud@latest/actions/learn-github-actions/contexts#needs-context), [`strategy`](/en/enterprise-cloud@latest/actions/learn-github-actions/contexts#strategy-context), and [`matrix`](/en/enterprise-cloud@latest/actions/learn-github-actions/contexts#matrix-context). For more information about expressions, see [Evaluate expressions in workflows and actions](/en/enterprise-cloud@latest/actions/learn-github-actions/expressions).\n\n### Example: Using an expression as environment name\n\n```yaml\nenvironment:\n  name: ${{ github.ref_name }}\n```\n\n### Example: Using an environment without creating a deployment\n\nSet `deployment` to `false` to use an environment's secrets and variables without creating a deployment object.\n\n```yaml\nenvironment:\n  name: testing\n  deployment: false\n```\n\nSetting `deployment: false` is not compatible with custom deployment protection rules.\nFor more information, see [Deploying with GitHub Actions](/en/enterprise-cloud@latest/actions/how-tos/deploy/configure-and-manage-deployments/control-deployments#using-environments-without-deployments).\n\n## `jobs.<job_id>.concurrency`\n\nYou can use `jobs.<job_id>.concurrency` to ensure that only a single job or workflow using the same concurrency group will run at a time. A concurrency group can be any string or expression. Allowed expression contexts: [`github`](/en/enterprise-cloud@latest/actions/learn-github-actions/contexts#github-context), [`inputs`](/en/enterprise-cloud@latest/actions/learn-github-actions/contexts#inputs-context), [`vars`](/en/enterprise-cloud@latest/actions/learn-github-actions/contexts#vars-context), [`needs`](/en/enterprise-cloud@latest/actions/learn-github-actions/contexts#needs-context), [`strategy`](/en/enterprise-cloud@latest/actions/learn-github-actions/contexts#strategy-context), and [`matrix`](/en/enterprise-cloud@latest/actions/learn-github-actions/contexts#matrix-context). For more information about expressions, see [Evaluate expressions in workflows and actions](/en/enterprise-cloud@latest/actions/learn-github-actions/expressions).\n\nYou can also specify `concurrency` at the workflow level. For more information, see [`concurrency`](/en/enterprise-cloud@latest/actions/using-workflows/workflow-syntax-for-github-actions#concurrency).\n\nThis means that there can be at most one running and one pending job in a concurrency group at any time. When a concurrent job or workflow is queued, if another job or workflow using the same concurrency group in the repository is in progress, the queued job or workflow will be `pending`. Any existing `pending` job or workflow in the same concurrency group, if it exists, will be canceled and the new queued job or workflow will take its place.\n\nTo also cancel any currently running job or workflow in the same concurrency group, specify `cancel-in-progress: true`. To conditionally cancel currently running jobs or workflows in the same concurrency group, you can specify `cancel-in-progress` as an expression with any of the allowed expression contexts.\n\n> \\[!NOTE]\n>\n> * The concurrency group name is case insensitive. For example, `prod` and `Prod` will be treated as the same concurrency group.\n> * Ordering is not guaranteed for jobs or workflow runs using concurrency groups. Jobs or workflow runs in the same concurrency group are handled in an arbitrary order.\n\n### Example: Using concurrency and the default behavior\n\nThe default behavior of GitHub Actions is to allow multiple jobs or workflow runs to run concurrently. The `concurrency` keyword allows you to control the concurrency of workflow runs.\n\nFor example, you can use the `concurrency` keyword immediately after where trigger conditions are defined to limit the concurrency of entire workflow runs for a specific branch:\n\n```yaml\non:\n  push:\n    branches:\n      - main\n\nconcurrency:\n  group: ${{ github.workflow }}-${{ github.ref }}\n  cancel-in-progress: true\n```\n\nYou can also limit the concurrency of jobs within a workflow by using the `concurrency` keyword at the job level:\n\n```yaml\non:\n  push:\n    branches:\n      - main\n\njobs:\n  job-1:\n    runs-on: ubuntu-latest\n    concurrency:\n      group: example-group\n      cancel-in-progress: true\n```\n\n### Example: Concurrency groups\n\nConcurrency groups provide a way to manage and limit the execution of workflow runs or jobs that share the same concurrency key.\n\nThe `concurrency` key is used to group workflows or jobs together into a concurrency group. When you define a `concurrency` key, GitHub Actions ensures that only one workflow or job with that key runs at any given time. If a new workflow run or job starts with the same `concurrency` key, GitHub Actions will cancel any workflow or job already running with that key. The `concurrency` key can be a hard-coded string, or it can be a dynamic expression that includes context variables.\n\nIt is possible to define concurrency conditions in your workflow so that the workflow or job is part of a concurrency group.\n\nThis means that when a workflow run or job starts, GitHub will cancel any workflow runs or jobs that are already in progress in the same concurrency group. This is useful in scenarios where you want to prevent parallel runs for a certain set of a workflows or jobs, such as the ones used for deployments to a staging environment, in order to prevent actions that could cause conflicts or consume more resources than necessary.\n\nIn this example, `job-1` is part of a concurrency group named `staging_environment`. This means that if a new run of `job-1` is triggered, any runs of the same job in the `staging_environment` concurrency group that are already in progress will be cancelled.\n\n```yaml\njobs:\n  job-1:\n    runs-on: ubuntu-latest\n    concurrency:\n      group: staging_environment\n      cancel-in-progress: true\n```\n\nAlternatively, using a dynamic expression such as `concurrency: ci-${{ github.ref }}` in your workflow means that the workflow or job would be part of a concurrency group named `ci-` followed by the reference of the branch or tag that triggered the workflow. In this example, if a new commit is pushed to the main branch while a previous run is still in progress, the previous run will be cancelled and the new one will start:\n\n```yaml\non:\n  push:\n    branches:\n      - main\n\nconcurrency:\n  group: ci-${{ github.ref }}\n  cancel-in-progress: true\n```\n\n### Example: Using concurrency to cancel any in-progress job or run\n\nTo use concurrency to cancel any in-progress job or run in GitHub Actions, you can use the `concurrency` key with the `cancel-in-progress` option set to `true`:\n\n```yaml\nconcurrency:\n  group: ${{ github.ref }}\n  cancel-in-progress: true\n```\n\nNote that in this example, without defining a particular concurrency group, GitHub Actions will cancel *any* in-progress run of the job or workflow.\n\n### Example: Using a fallback value\n\nIf you build the group name with a property that is only defined for specific events, you can use a fallback value. For example, `github.head_ref` is only defined on `pull_request` events. If your workflow responds to other events in addition to `pull_request` events, you will need to provide a fallback to avoid a syntax error. The following concurrency group cancels in-progress jobs or runs on `pull_request` events only; if `github.head_ref` is undefined, the concurrency group will fallback to the run ID, which is guaranteed to be both unique and defined for the run.\n\n```yaml\nconcurrency:\n  group: ${{ github.head_ref || github.run_id }}\n  cancel-in-progress: true\n```\n\n### Example: Only cancel in-progress jobs or runs for the current workflow\n\nIf you have multiple workflows in the same repository, concurrency group names must be unique across workflows to avoid canceling in-progress jobs or runs from other workflows. Otherwise, any previously in-progress or pending job will be canceled, regardless of the workflow.\n\nTo only cancel in-progress runs of the same workflow, you can use the `github.workflow` property to build the concurrency group:\n\n```yaml\nconcurrency:\n  group: ${{ github.workflow }}-${{ github.ref }}\n  cancel-in-progress: true\n```\n\n### Example: Only cancel in-progress jobs on specific branches\n\nIf you would like to cancel in-progress jobs on certain branches but not on others, you can use conditional expressions with `cancel-in-progress`. For example, you can do this if you would like to cancel in-progress jobs on development branches but not on release branches.\n\nTo only cancel in-progress runs of the same workflow when not running on a release branch, you can set `cancel-in-progress` to an expression similar to the following:\n\n```yaml\nconcurrency:\n  group: ${{ github.workflow }}-${{ github.ref }}\n  cancel-in-progress: ${{ !contains(github.ref, 'release/')}}\n```\n\nIn this example, multiple pushes to a `release/1.2.3` branch would not cancel in-progress runs. Pushes to another branch, such as `main`, would cancel in-progress runs.\n\n## `jobs.<job_id>.outputs`\n\nYou can use `jobs.<job_id>.outputs` to create 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`](/en/enterprise-cloud@latest/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idneeds).\n\nOutputs can be a maximum of 1 MB per job. The total of all outputs in a workflow run can be a maximum of 50 MB. Size is approximated based on UTF-16 encoding.\n\nJob outputs containing expressions are evaluated on the runner at the end of each job. Outputs containing secrets are redacted on the runner and not sent to GitHub Actions.\n\nIf an output is skipped because it may contain a secret, you will see the following warning message: \"Skip output `{output.Key}` since it may contain secret.\" For more information on how to handle secrets, please refer to the [Example: Masking and passing a secret between jobs or workflows](/en/enterprise-cloud@latest/actions/writing-workflows/choosing-what-your-workflow-does/workflow-commands-for-github-actions#example-masking-and-passing-a-secret-between-jobs-or-workflows).\n\nTo use job outputs in a dependent job, you can use the `needs` context. For more information, see [Contexts reference](/en/enterprise-cloud@latest/actions/learn-github-actions/contexts#needs-context).\n\n### Example: Defining outputs for a job\n\n```yaml\njobs:\n  job1:\n    runs-on: ubuntu-latest\n    # Map a step output to a job output\n    outputs:\n      output1: ${{ steps.step1.outputs.test }}\n      output2: ${{ steps.step2.outputs.test }}\n    steps:\n      - id: step1\n        run: echo \"test=hello\" >> \"$GITHUB_OUTPUT\"\n      - id: step2\n        run: echo \"test=world\" >> \"$GITHUB_OUTPUT\"\n  job2:\n    runs-on: ubuntu-latest\n    needs: job1\n    steps:\n      - env:\n          OUTPUT1: ${{needs.job1.outputs.output1}}\n          OUTPUT2: ${{needs.job1.outputs.output2}}\n        run: echo \"$OUTPUT1 $OUTPUT2\"\n```\n\n### Using Job Outputs in a Matrix Job\n\nMatrices can be used to generate multiple outputs of different names. When using a matrix, job outputs will be combined from all jobs inside the matrix.\n\n```yaml\njobs:\n  job1:\n    runs-on: ubuntu-latest\n    outputs:\n      output_1: ${{ steps.gen_output.outputs.output_1 }}\n      output_2: ${{ steps.gen_output.outputs.output_2 }}\n      output_3: ${{ steps.gen_output.outputs.output_3 }}\n    strategy:\n      matrix:\n        version: [1, 2, 3]\n    steps:\n      - name: Generate output\n        id: gen_output\n        run: |\n          version=\"${{ matrix.version }}\"\n          echo \"output_${version}=${version}\" >> \"$GITHUB_OUTPUT\"\n  job2:\n    runs-on: ubuntu-latest\n    needs: [job1]\n    steps:\n      # Will show\n      # {\n      #   \"output_1\": \"1\",\n      #   \"output_2\": \"2\",\n      #   \"output_3\": \"3\"\n      # }\n      - run: echo '${{ toJSON(needs.job1.outputs) }}'\n```\n\n> \\[!WARNING]\n> Actions does not guarantee the order that matrix jobs will run in. Ensure that the output name is unique, otherwise the last matrix job that runs will override the output value.\n\n## `jobs.<job_id>.env`\n\nA `map` of variables that are available to all steps in the job. You can set variables for the entire workflow or an individual step. For more information, see [`env`](#env) and [`jobs.<job_id>.steps[*].env`](#jobsjob_idstepsenv).\n\nWhen more than one environment variable is defined with the same name, GitHub uses the most specific variable. For example, an environment variable defined in a step will override job and workflow environment variables with the same name, while the step executes. An environment variable defined for a job will override a workflow variable with the same name, while the job executes.\n\n### Example of `jobs.<job_id>.env`\n\n```yaml\njobs:\n  job1:\n    env:\n      FIRST_NAME: Mona\n```\n\n## `jobs.<job_id>.defaults`\n\nUse `jobs.<job_id>.defaults` to create 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`](/en/enterprise-cloud@latest/actions/using-workflows/workflow-syntax-for-github-actions#defaults).\n\nWhen more than one default setting is defined with the same name, GitHub uses the most specific default setting. For example, a default setting defined in a job will override a default setting that has the same name defined in a workflow.\n\n## `jobs.<job_id>.defaults.run`\n\nUse `jobs.<job_id>.defaults.run` to provide default `shell` and `working-directory` to all `run` steps in the job.\n\nYou can provide default `shell` and `working-directory` options for all [`run`](/en/enterprise-cloud@latest/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepsrun) steps in a job. You can also set default settings for `run` for the entire workflow. For more information, see [`defaults.run`](/en/enterprise-cloud@latest/actions/using-workflows/workflow-syntax-for-github-actions#defaultsrun).\n\nThese can be overridden at the `jobs.<job_id>.defaults.run` and `jobs.<job_id>.steps[*].run` levels.\n\nWhen more than one default setting is defined with the same name, GitHub uses the most specific default setting. For example, a default setting defined in a job will override a default setting that has the same name defined in a workflow.\n\n## `jobs.<job_id>.defaults.run.shell`\n\nUse `shell` to define the `shell` for a step. This keyword can reference several contexts. For more information, see [Contexts](/en/enterprise-cloud@latest/actions/learn-github-actions/contexts#context-availability).\n\n| Supported platform | `shell` parameter | Description                                                                                                                                                                                                                                       | Command run internally                          |\n| ------------------ | ----------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------- |\n| Linux / macOS      | unspecified       | The default shell on non-Windows platforms. Note that this runs a different command to when `bash` is specified explicitly. If `bash` is not found in the path, this is treated as `sh`.                                                          | `bash -e {0}`                                   |\n| All                | `bash`            | The default shell on non-Windows platforms with a fallback to `sh`. When specifying a bash shell on Windows, the bash shell included with Git for Windows is used.                                                                                | `bash --noprofile --norc -eo pipefail {0}`      |\n| All                | `pwsh`            | The PowerShell Core. GitHub appends the extension `.ps1` to your script name.                                                                                                                                                                     | `pwsh -command \". '{0}'\"`                       |\n| All                | `python`          | Executes the python command.                                                                                                                                                                                                                      | `python {0}`                                    |\n| Linux / macOS      | `sh`              | The fallback behavior for non-Windows platforms if no shell is provided and `bash` is not found in the path.                                                                                                                                      | `sh -e {0}`                                     |\n| Windows            | `cmd`             | GitHub appends the extension `.cmd` to your script name and substitutes for `{0}`.                                                                                                                                                                | `%ComSpec% /D /E:ON /V:OFF /S /C \"CALL \"{0}\"\"`. |\n| Windows            | `pwsh`            | This is the default shell used on Windows. The PowerShell Core. GitHub 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}'\"`.                      |\n| Windows            | `powershell`      | The PowerShell Desktop. GitHub appends the extension `.ps1` to your script name.                                                                                                                                                                  | `powershell -command \". '{0}'\"`.                |\n\nWhen more than one default setting is defined with the same name, GitHub uses the most specific default setting. For example, a default setting defined in a job will override a default setting that has the same name defined in a workflow.\n\n## `jobs.<job_id>.defaults.run.working-directory`\n\nUse `working-directory` to define the working directory for the `shell` for a step. This keyword can reference several contexts. For more information, see [Contexts](/en/enterprise-cloud@latest/actions/learn-github-actions/contexts#context-availability).\n\n> \\[!TIP]\n> Ensure the `working-directory` you assign exists on the runner before you run your shell in it.\n> When more than one default setting is defined with the same name, GitHub uses the most specific default setting. For example, a default setting defined in a job will override a default setting that has the same name defined in a workflow.\n\n### Example: Setting default `run` step options for a job\n\n```yaml\njobs:\n  job1:\n    runs-on: ubuntu-latest\n    defaults:\n      run:\n        shell: bash\n        working-directory: ./scripts\n```\n\n## `jobs.<job_id>.steps`\n\nA 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. GitHub provides built-in steps to set up and complete a job.\n\nGitHub only displays the first 1,000 checks, however, you can run an unlimited number of steps as long as you are within the workflow usage limits. For more information, see [Billing and usage](/en/enterprise-cloud@latest/actions/learn-github-actions/usage-limits-billing-and-administration) for GitHub-hosted runners and [Actions limits](/en/enterprise-cloud@latest/actions/hosting-your-own-runners/managing-self-hosted-runners/usage-limits-for-self-hosted-runners) for self-hosted runner usage limits.\n\n### Example of `jobs.<job_id>.steps`\n\n```yaml\nname: Greeting from Mona\n\non: push\n\njobs:\n  my-job:\n    name: My Job\n    runs-on: ubuntu-latest\n    steps:\n      - name: Print a greeting\n        env:\n          MY_VAR: Hi there! My name is\n          FIRST_NAME: Mona\n          MIDDLE_NAME: The\n          LAST_NAME: Octocat\n        run: |\n          echo $MY_VAR $FIRST_NAME $MIDDLE_NAME $LAST_NAME.\n```\n\n## `jobs.<job_id>.steps[*].id`\n\nA unique identifier for the step. You can use the `id` to reference the step in contexts. For more information, see [Contexts reference](/en/enterprise-cloud@latest/actions/learn-github-actions/contexts).\n\n## `jobs.<job_id>.steps[*].if`\n\nYou 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. For more information on which contexts are supported in this key, see [Contexts reference](/en/enterprise-cloud@latest/actions/learn-github-actions/contexts#context-availability).\n\nWhen you use expressions in an `if` conditional, you can, optionally, omit the `${{ }}` expression syntax because GitHub Actions automatically evaluates the `if` conditional as an expression. However, this exception does not apply everywhere.\n\nYou must always use the `${{ }}` expression syntax or escape with `''`, `\"\"`, or `()` when the expression starts with `!`, since `!` is reserved notation in YAML format. For example:\n\n```yaml\nif: ${{ ! startsWith(github.ref, 'refs/tags/') }}\n```\n\nFor more information, see [Evaluate expressions in workflows and actions](/en/enterprise-cloud@latest/actions/learn-github-actions/expressions).\n\n### Example: Using contexts\n\nThis step only runs when the event type is a `pull_request` and the event action is `unassigned`.\n\n```yaml\nsteps:\n  - name: My first step\n    if: ${{ github.event_name == 'pull_request' && github.event.action == 'unassigned' }}\n    run: echo This event is a pull request that had an assignee removed.\n```\n\n### Example: Using status check functions\n\nThe `my backup step` only runs when the previous step of a job fails. For more information, see [Evaluate expressions in workflows and actions](/en/enterprise-cloud@latest/actions/learn-github-actions/expressions#status-check-functions).\n\n```yaml\nsteps:\n  - name: My first step\n    uses: octo-org/action-name@main\n  - name: My backup step\n    if: ${{ failure() }}\n    uses: actions/heroku@1.0.0\n```\n\n### Example: Using secrets\n\nSecrets cannot be directly referenced in `if:` conditionals. Instead, consider setting secrets as job-level environment variables, then referencing the environment variables to conditionally run steps in the job.\n\nIf a secret has not been set, the return value of an expression referencing the secret (such as `${{ secrets.SuperSecret }}` in the example) will be an empty string.\n\n```yaml\nname: Run a step if a secret has been set\non: push\njobs:\n  my-jobname:\n    runs-on: ubuntu-latest\n    env:\n      super_secret: ${{ secrets.SuperSecret }}\n    steps:\n      - if: ${{ env.super_secret != '' }}\n        run: echo 'This step will only run if the secret has a value set.'\n      - if: ${{ env.super_secret == '' }}\n        run: echo 'This step will only run if the secret does not have a value set.'\n```\n\nFor more information, see [Contexts reference](/en/enterprise-cloud@latest/actions/learn-github-actions/contexts#context-availability) and [Using secrets in GitHub Actions](/en/enterprise-cloud@latest/actions/security-guides/using-secrets-in-github-actions).\n\n## `jobs.<job_id>.steps[*].name`\n\nA name for your step to display on GitHub.\n\n## `jobs.<job_id>.steps[*].uses`\n\nSelects 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/).\n\nWe strongly recommend that you include the version of the action you are using by specifying a Git ref, SHA, or Docker tag. If you don't specify a version, it could break your workflows or cause unexpected behavior when the action owner publishes an update.\n\n* Using the commit SHA of a released action version is the safest for stability and security.\n* If the action publishes major version tags, you should expect to receive critical fixes and security patches while still retaining compatibility. Note that this behavior is at the discretion of the action's author.\n* Using the default branch of an action may be convenient, but if someone releases a new major version with a breaking change, your workflow could break.\n\nSome actions require inputs that you must set using the [`with`](#jobsjob_idstepswith) keyword. Review the action's README file to determine the inputs required.\n\nActions 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).\n\n### Example: Using versioned actions\n\n```yaml\nsteps:\n  # Reference a specific commit\n  - uses: actions/checkout@8f4b7f84864484a7bf31766abe9204da3cbe65b3\n  # Reference the major version of a release\n  - uses: actions/checkout@v6\n  # Reference a specific version\n  - uses: actions/checkout@v6.2.0\n  # Reference a branch\n  - uses: actions/checkout@main\n```\n\n### Example: Using a public action\n\n`{owner}/{repo}@{ref}`\n\nYou can specify a branch, ref, or SHA in a public GitHub repository.\n\n```yaml\njobs:\n  my_first_job:\n    steps:\n      - name: My first step\n        # Uses the default branch of a public repository\n        uses: actions/heroku@main\n      - name: My second step\n        # Uses a specific version tag of a public repository\n        uses: actions/aws@v2.0.1\n```\n\n### Example: Using a public action in a subdirectory\n\n`{owner}/{repo}/{path}@{ref}`\n\nA subdirectory in a public GitHub repository at a specific branch, ref, or SHA.\n\n```yaml\njobs:\n  my_first_job:\n    steps:\n      - name: My first step\n        uses: actions/aws/ec2@main\n```\n\n### Example: Using an action in the same repository as the workflow\n\n`./path/to/dir`\n\nThe path to the directory that contains the action in your workflow's repository. You must check out your repository before using the action.\n\nExample repository file structure:\n\n```shell\n|-- hello-world (repository)\n|   |__ .github\n|       └── workflows\n|           └── my-first-workflow.yml\n|       └── actions\n|           |__ hello-world-action\n|               └── action.yml\n```\n\nThe path is relative (`./`) to the default working directory (`github.workspace`, `$GITHUB_WORKSPACE`). If the action checks out the repository to a location different than the workflow, the relative path used for local actions must be updated.\n\nExample workflow file:\n\n```yaml\njobs:\n  my_first_job:\n    runs-on: ubuntu-latest\n    steps:\n      # This step checks out a copy of your repository.\n      - name: My first step - check out repository\n        uses: actions/checkout@v6\n      # This step references the directory that contains the action.\n      - name: Use local hello-world-action\n        uses: ./.github/actions/hello-world-action\n```\n\n### Example: Using a Docker Hub action\n\n`docker://{image}:{tag}`\n\nA Docker image published on [Docker Hub](https://hub.docker.com/).\n\n```yaml\njobs:\n  my_first_job:\n    steps:\n      - name: My first step\n        uses: docker://alpine:3.8\n```\n\n### Example: Using the GitHub Packages Container registry\n\n`docker://{host}/{image}:{tag}`\n\nA public Docker image in the GitHub Packages Container registry.\n\n```yaml\njobs:\n  my_first_job:\n    steps:\n      - name: My first step\n        uses: docker://ghcr.io/OWNER/IMAGE_NAME\n```\n\n### Example: Using a Docker public registry action\n\n`docker://{host}/{image}:{tag}`\n\nA Docker image in a public registry. This example uses the Google Container Registry at `gcr.io`.\n\n```yaml\njobs:\n  my_first_job:\n    steps:\n      - name: My first step\n        uses: docker://gcr.io/cloud-builders/gradle\n```\n\n### Example: Using an action inside a different private repository than the workflow\n\nYour workflow must checkout the private repository and reference the action locally. Generate a personal access token and add the token as a secret. For more information, see [Managing your personal access tokens](/en/enterprise-cloud@latest/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token) and [Using secrets in GitHub Actions](/en/enterprise-cloud@latest/actions/security-guides/using-secrets-in-github-actions).\n\nReplace `PERSONAL_ACCESS_TOKEN` in the example with the name of your secret.\n\n```yaml\njobs:\n  my_first_job:\n    steps:\n      - name: Check out repository\n        uses: actions/checkout@v6\n        with:\n          repository: octocat/my-private-repo\n          ref: v1.0\n          token: ${{ secrets.PERSONAL_ACCESS_TOKEN }}\n          path: ./.github/actions/my-private-repo\n      - name: Run my action\n        uses: ./.github/actions/my-private-repo/my-action\n```\n\nAlternatively, use a GitHub App instead of a personal access token in order to ensure your workflow continues to run even if the personal access token owner leaves. For more information, see [Making authenticated API requests with a GitHub App in a GitHub Actions workflow](/en/enterprise-cloud@latest/apps/creating-github-apps/guides/making-authenticated-api-requests-with-a-github-app-in-a-github-actions-workflow).\n\n## `jobs.<job_id>.steps[*].run`\n\nRuns command-line programs that do not exceed 21,000 characters 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.\n\nCommands run using non-login shells by default. You can choose a different shell and customize the shell used to run commands. For more information, see [`jobs.<job_id>.steps[*].shell`](#jobsjob_idstepsshell).\n\nEach `run` keyword represents a new process and shell in the runner environment. When you provide multi-line commands, each line runs in the same shell. For example:\n\n* A single-line command:\n\n  ```yaml\n  - name: Install Dependencies\n    run: npm install\n  ```\n\n* A multi-line command:\n\n  ```yaml\n  - name: Clean install dependencies and build\n    run: |\n      npm ci\n      npm run build\n  ```\n\n## `jobs.<job_id>.steps[*].working-directory`\n\nUsing the `working-directory` keyword, you can specify the working directory of where to run the command.\n\n```yaml\n- name: Clean temp directory\n  run: rm -rf *\n  working-directory: ./temp\n```\n\nAlternatively, you can specify a default working directory for all `run` steps in a job, or for all `run` steps in the entire workflow. For more information, see [`defaults.run.working-directory`](/en/enterprise-cloud@latest/actions/using-workflows/workflow-syntax-for-github-actions#defaultsrunworking-directory) and [`jobs.<job_id>.defaults.run.working-directory`](/en/enterprise-cloud@latest/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_iddefaultsrunworking-directory).\n\nYou can also use a `run` step to run a script. For more information, see [Adding scripts to your workflow](/en/enterprise-cloud@latest/actions/writing-workflows/choosing-what-your-workflow-does/adding-scripts-to-your-workflow).\n\n## `jobs.<job_id>.steps[*].shell`\n\nYou can override the default shell settings in the runner's operating system and the job's default using the `shell` keyword. You can use built-in `shell` keywords, or you can define a custom set of shell options. The shell command that is run internally executes a temporary file that contains the commands specified in the `run` keyword.\n\n| Supported platform | `shell` parameter | Description                                                                                                                                                                                                                                       | Command run internally                          |\n| ------------------ | ----------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------- |\n| Linux / macOS      | unspecified       | The default shell on non-Windows platforms. Note that this runs a different command to when `bash` is specified explicitly. If `bash` is not found in the path, this is treated as `sh`.                                                          | `bash -e {0}`                                   |\n| All                | `bash`            | The default shell on non-Windows platforms with a fallback to `sh`. When specifying a bash shell on Windows, the bash shell included with Git for Windows is used.                                                                                | `bash --noprofile --norc -eo pipefail {0}`      |\n| All                | `pwsh`            | The PowerShell Core. GitHub appends the extension `.ps1` to your script name.                                                                                                                                                                     | `pwsh -command \". '{0}'\"`                       |\n| All                | `python`          | Executes the python command.                                                                                                                                                                                                                      | `python {0}`                                    |\n| Linux / macOS      | `sh`              | The fallback behavior for non-Windows platforms if no shell is provided and `bash` is not found in the path.                                                                                                                                      | `sh -e {0}`                                     |\n| Windows            | `cmd`             | GitHub appends the extension `.cmd` to your script name and substitutes for `{0}`.                                                                                                                                                                | `%ComSpec% /D /E:ON /V:OFF /S /C \"CALL \"{0}\"\"`. |\n| Windows            | `pwsh`            | This is the default shell used on Windows. The PowerShell Core. GitHub 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}'\"`.                      |\n| Windows            | `powershell`      | The PowerShell Desktop. GitHub appends the extension `.ps1` to your script name.                                                                                                                                                                  | `powershell -command \". '{0}'\"`.                |\n\nAlternatively, you can specify a default shell for all `run` steps in a job, or for all `run` steps in the entire workflow. For more information, see [`defaults.run.shell`](/en/enterprise-cloud@latest/actions/using-workflows/workflow-syntax-for-github-actions#defaultsrunshell) and [`jobs.<job_id>.defaults.run.shell`](/en/enterprise-cloud@latest/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_iddefaultsrunshell).\n\n### Example: Running a command using Bash\n\n```yaml\nsteps:\n  - name: Display the path\n    shell: bash\n    run: echo $PATH\n```\n\n### Example: Running a command using Windows `cmd`\n\n```yaml\nsteps:\n  - name: Display the path\n    shell: cmd\n    run: echo %PATH%\n```\n\n### Example: Running a command using PowerShell Core\n\n```yaml\nsteps:\n  - name: Display the path\n    shell: pwsh\n    run: echo ${env:PATH}\n```\n\n### Example: Using PowerShell Desktop to run a command\n\n```yaml\nsteps:\n  - name: Display the path\n    shell: powershell\n    run: echo ${env:PATH}\n```\n\n### Example: Running an inline Python script\n\n```yaml\nsteps:\n  - name: Display the path\n    shell: python\n    run: |\n      import os\n      print(os.environ['PATH'])\n```\n\n### Custom shell\n\nYou can set the `shell` value to a template string using `command [options] {0} [more_options]`. GitHub interprets the first whitespace-delimited word of the string as the command, and inserts the file name for the temporary script at `{0}`.\n\nFor example:\n\n```yaml\nsteps:\n  - name: Display the environment variables and their values\n    shell: perl {0}\n    run: |\n      print %ENV\n```\n\nThe command used, `perl` in this example, must be installed on the runner.\n\nFor information about the software included on GitHub-hosted runners, see [GitHub-hosted runners](/en/enterprise-cloud@latest/actions/using-github-hosted-runners/about-github-hosted-runners#supported-software).\n\n### Exit codes and error action preference\n\nFor built-in shell keywords, we provide the following defaults that are executed by GitHub-hosted runners. You should use these guidelines when running shell scripts.\n\n* `bash`/`sh`:\n  * By default, fail-fast behavior is enforced using `set -e` for both `sh` and `bash`. When `shell: bash` is specified, `-o pipefail` is also applied to enforce early exit from pipelines that generate a non-zero exit status.\n  * You can take full control over shell parameters by providing a template string to the shell options. For example, `bash {0}`.\n  * `sh`-like shells exit with the exit code of the last command executed in a script, which is also the default behavior for actions. The runner will report the status of the step as fail/succeed based on this exit code.\n\n* `powershell`/`pwsh`\n  * Fail-fast behavior when possible. For `pwsh` and `powershell` built-in shell, we will prepend `$ErrorActionPreference = 'stop'` to script contents.\n  * We append `if ((Test-Path -LiteralPath variable:\\LASTEXITCODE)) { exit $LASTEXITCODE }` to powershell scripts so action statuses reflect the script's last exit code.\n  * Users can always opt out by not using the built-in shell, and providing a custom shell option like: `pwsh -File {0}`, or `powershell -Command \"& '{0}'\"`, depending on need.\n\n* `cmd`\n  * 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.\n  * `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.\n\n## `jobs.<job_id>.steps[*].with`\n\nA `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.\n\nInput parameters defined for a Docker container must use `args`. For more information, see [`jobs.<job_id>.steps[*].with.args`](#jobsjob_idstepswithargs).\n\n### Example of `jobs.<job_id>.steps[*].with`\n\nDefines 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.\n\n```yaml\njobs:\n  my_first_job:\n    steps:\n      - name: My first step\n        uses: actions/hello_world@main\n        with:\n          first_name: Mona\n          middle_name: The\n          last_name: Octocat\n```\n\n## `jobs.<job_id>.steps[*].with.args`\n\nA `string` that defines the inputs for a Docker container. GitHub passes the `args` to the container's `ENTRYPOINT` when the container starts up. An `array of strings` is not supported by this parameter. A single argument that includes spaces should be surrounded by double quotes `\"\"`.\n\n### Example of `jobs.<job_id>.steps[*].with.args`\n\n```yaml\nsteps:\n  - name: Explain why this job ran\n    uses: octo-org/action-name@main\n    with:\n      entrypoint: /bin/echo\n      args: The ${{ github.event_name }} event triggered this step.\n```\n\nThe `args` are used in place of the `CMD` instruction in a `Dockerfile`. If you use `CMD` in your `Dockerfile`, use the guidelines ordered by preference:\n\n1. Document required arguments in the action's README and omit them from the `CMD` instruction.\n2. Use defaults that allow using the action without specifying any `args`.\n3. If the action exposes a `--help` flag, or something similar, use that as the default to make your action self-documenting.\n\n## `jobs.<job_id>.steps[*].with.entrypoint`\n\nOverrides 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.\n\n### Example of `jobs.<job_id>.steps[*].with.entrypoint`\n\n```yaml\nsteps:\n  - name: Run a custom command\n    uses: octo-org/action-name@main\n    with:\n      entrypoint: /a/different/executable\n```\n\nThe `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.\n\n## `jobs.<job_id>.steps[*].env`\n\nSets variables for steps to use in the runner environment. You can also set variables for the entire workflow or a job. For more information, see [`env`](#env) and [`jobs.<job_id>.env`](#jobsjob_idenv).\n\nWhen more than one environment variable is defined with the same name, GitHub uses the most specific variable. For example, an environment variable defined in a step will override job and workflow environment variables with the same name, while the step executes. An environment variable defined for a job will override a workflow variable with the same name, while the job executes.\n\nPublic actions may specify expected variables in the README file. If you are setting a secret or sensitive value, such as a password or token, you must set secrets using the `secrets` context. For more information, see [Contexts reference](/en/enterprise-cloud@latest/actions/learn-github-actions/contexts).\n\n### Example of `jobs.<job_id>.steps[*].env`\n\n```yaml\nsteps:\n  - name: My first action\n    env:\n      GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}\n      FIRST_NAME: Mona\n      LAST_NAME: Octocat\n```\n\n## `jobs.<job_id>.steps[*].continue-on-error`\n\nPrevents a job from failing when a step fails. Set to `true` to allow a job to pass when this step fails.\n\n## `jobs.<job_id>.steps[*].timeout-minutes`\n\nThe maximum number of minutes to run the step before killing the process. Maximum: 360 for both GitHub-hosted and self-hosted runners.\n\nFractional values are not supported. `timeout-minutes` must be a positive integer.\n\n## `jobs.<job_id>.timeout-minutes`\n\nThe maximum number of minutes to let a job run before GitHub automatically cancels it. Default: 360\n\nIf the timeout exceeds the job execution time limit for the runner, the job will be canceled when the execution time limit is met instead. For more information about job execution time limits, see [Billing and usage](/en/enterprise-cloud@latest/actions/learn-github-actions/usage-limits-billing-and-administration#usage-limits) for GitHub-hosted runners and [Actions limits](/en/enterprise-cloud@latest/actions/hosting-your-own-runners/managing-self-hosted-runners/usage-limits-for-self-hosted-runners) for self-hosted runner usage limits.\n\n> \\[!NOTE]\n> The `GITHUB_TOKEN` expires when a job finishes or after a maximum of 24 hours. For self-hosted runners, the token may be the limiting factor if the job timeout is greater than 24 hours. For more information on the `GITHUB_TOKEN`, see [Use GITHUB\\_TOKEN for authentication in workflows](/en/enterprise-cloud@latest/actions/security-guides/automatic-token-authentication#about-the-github_token-secret).\n\n## `jobs.<job_id>.strategy`\n\nUse `jobs.<job_id>.strategy` to use a matrix strategy for your jobs. A matrix strategy lets you use variables in a single job definition to automatically create multiple job runs that are based on 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. For more information, see [Running variations of jobs in a workflow](/en/enterprise-cloud@latest/actions/using-jobs/using-a-matrix-for-your-jobs).\n\n## `jobs.<job_id>.strategy.matrix`\n\nUse `jobs.<job_id>.strategy.matrix` to define a matrix of different job configurations. For more information, see [Running variations of jobs in a workflow](/en/enterprise-cloud@latest/actions/how-tos/writing-workflows/choosing-what-your-workflow-does/running-variations-of-jobs-in-a-workflow).\n\nA matrix will generate a maximum of 256 jobs per workflow run. This limit applies to both GitHub-hosted and self-hosted runners.\n\nThe 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 reference](/en/enterprise-cloud@latest/actions/learn-github-actions/contexts).\n\nBy default, GitHub will maximize the number of jobs run in parallel depending on runner availability. The order of the variables in the matrix determines the order in which the jobs are created. The first variable you define will be the first job that is created in your workflow run.\n\n### Using a single-dimension matrix\n\nThe 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.\n\n```yaml\njobs:\n  example_matrix:\n    strategy:\n      matrix:\n        version: [10, 12, 14]\n    steps:\n      - uses: actions/setup-node@v4\n        with:\n          node-version: ${{ matrix.version }}\n```\n\n### Using a multi-dimensional matrix\n\nSpecify multiple variables to create a multi-dimensional matrix. A job will run for each possible combination of the variables.\n\nFor example, the following workflow specifies two variables:\n\n* Two operating systems specified in the `os` variable\n* Three Node.js versions specified in the `version` variable\n\nThe 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.\n\n```yaml\njobs:\n  example_matrix:\n    strategy:\n      matrix:\n        os: [ubuntu-22.04, ubuntu-24.04]\n        version: [10, 12, 14]\n    runs-on: ${{ matrix.os }}\n    steps:\n      - uses: actions/setup-node@v4\n        with:\n          node-version: ${{ matrix.version }}\n```\n\nA variable configuration in a matrix can be an `array` of `object`s. For example, the following matrix produces 4 jobs with corresponding contexts.\n\n```yaml\nmatrix:\n  os:\n    - ubuntu-latest\n    - macos-latest\n  node:\n    - version: 14\n    - version: 20\n      env: NODE_OPTIONS=--openssl-legacy-provider\n```\n\nEach job in the matrix will have its own combination of `os` and `node` values, as shown below.\n\n```yaml\n- matrix.os: ubuntu-latest\n  matrix.node.version: 14\n- matrix.os: ubuntu-latest\n  matrix.node.version: 20\n  matrix.node.env: NODE_OPTIONS=--openssl-legacy-provider\n- matrix.os: macos-latest\n  matrix.node.version: 14\n- matrix.os: macos-latest\n  matrix.node.version: 20\n  matrix.node.env: NODE_OPTIONS=--openssl-legacy-provider\n```\n\n## `jobs.<job_id>.strategy.matrix.include`\n\nFor 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.\n\n### Example: Expanding configurations\n\nFor example, the following workflow will run four 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.\n\n```yaml\njobs:\n  example_matrix:\n    strategy:\n      matrix:\n        os: [windows-latest, ubuntu-latest]\n        node: [14, 16]\n        include:\n          - os: windows-latest\n            node: 16\n            npm: 6\n    runs-on: ${{ matrix.os }}\n    steps:\n      - uses: actions/setup-node@v4\n        with:\n          node-version: ${{ matrix.node }}\n      - if: ${{ matrix.npm }}\n        run: npm install -g npm@${{ matrix.npm }}\n      - run: npm --version\n```\n\n### Example: Adding configurations\n\nFor 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`.\n\n```yaml\njobs:\n  example_matrix:\n    strategy:\n      matrix:\n        os: [macos-latest, windows-latest, ubuntu-latest]\n        version: [12, 14, 16]\n        include:\n          - os: windows-latest\n            version: 17\n```\n\nIf 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.\n\n```yaml\njobs:\n  includes_only:\n    runs-on: ubuntu-latest\n    strategy:\n      matrix:\n        include:\n          - site: \"production\"\n            datacenter: \"site-a\"\n          - site: \"staging\"\n            datacenter: \"site-b\"\n```\n\n## `jobs.<job_id>.strategy.matrix.exclude`\n\nAn excluded configuration only has to be a partial match for it to be excluded.\n\nAll `include` combinations are processed after `exclude`. This allows you to use `include` to add back combinations that were previously excluded.\n\n## `jobs.<job_id>.strategy.fail-fast`\n\nYou can control how job failures are handled with `jobs.<job_id>.strategy.fail-fast` and `jobs.<job_id>.continue-on-error`.\n\n`jobs.<job_id>.strategy.fail-fast` applies to the entire matrix. If `jobs.<job_id>.strategy.fail-fast` is set to `true` or its expression evaluates to `true`, GitHub will cancel all in-progress and queued jobs in the matrix if any job in the matrix fails. This property defaults to `true`.\n\n`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.\n\nYou 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.\n\n```yaml\njobs:\n  test:\n    runs-on: ubuntu-latest\n    continue-on-error: ${{ matrix.experimental }}\n    strategy:\n      fail-fast: true\n      matrix:\n        version: [6, 7, 8]\n        experimental: [false]\n        include:\n          - version: 9\n            experimental: true\n```\n\n## `jobs.<job_id>.strategy.max-parallel`\n\nBy default, GitHub will maximize the number of jobs run in parallel depending on runner availability.\n\n## `jobs.<job_id>.continue-on-error`\n\n`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.\n\nPrevents a workflow run from failing when a job fails. Set to `true` to allow a workflow run to pass when this job fails.\n\n### Example: Preventing a specific failing matrix job from failing a workflow run\n\nYou 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.\n\n```yaml\nruns-on: ${{ matrix.os }}\ncontinue-on-error: ${{ matrix.experimental }}\nstrategy:\n  fail-fast: false\n  matrix:\n    node: [13, 14]\n    os: [macos-latest, ubuntu-latest]\n    experimental: [false]\n    include:\n      - node: 15\n        os: ubuntu-latest\n        experimental: true\n```\n\n## `jobs.<job_id>.container`\n\n> \\[!NOTE]\n> If your workflows use Docker container actions, job containers, or service containers, then you must use a Linux runner:\n>\n> * If you are using GitHub-hosted runners, you must use an Ubuntu runner.\n> * If you are using self-hosted runners, you must use a Linux machine as your runner and Docker must be installed.\n\nUse `jobs.<job_id>.container` to create 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.\n\nIf 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.\n\n> \\[!NOTE]\n> The default shell for `run` steps inside a container is `sh` instead of `bash`. This can be overridden with [`jobs.<job_id>.defaults.run`](/en/enterprise-cloud@latest/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_iddefaultsrun) or [`jobs.<job_id>.steps[*].shell`](/en/enterprise-cloud@latest/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepsshell).\n\n### Example: Running a job within a container\n\n```yaml copy\nname: CI\non:\n  push:\n    branches: [ main ]\njobs:\n  container-test-job:\n    runs-on: ubuntu-latest\n    container:\n      image: node:18\n      env:\n        NODE_ENV: development\n      ports:\n        - 80\n      volumes:\n        - my_docker_volume:/volume_mount\n      options: --cpus 1\n    steps:\n      - name: Check for dockerenv file\n        run: (ls /.dockerenv && echo Found dockerenv) || (echo No dockerenv)\n```\n\nWhen you only specify a container image, you can omit the `image` keyword.\n\n```yaml\njobs:\n  container-test-job:\n    runs-on: ubuntu-latest\n    container: node:18\n```\n\n## `jobs.<job_id>.container.image`\n\nUse `jobs.<job_id>.container.image` to define the Docker image to use as the container to run the action. The value can be the Docker Hub image name or a registry name.\n\n> \\[!NOTE]\n> Docker Hub normally imposes rate limits on both push and pull operations which will affect jobs on self-hosted runners. However, GitHub-hosted runners are not subject to these limits based on an agreement between GitHub and Docker.\n\n## `jobs.<job_id>.container.credentials`\n\nIf the image's container registry requires authentication to pull the image, you can use `jobs.<job_id>.container.credentials` to set a `map` of the `username` and `password`. The credentials are the same values that you would provide to the [`docker login`](https://docs.docker.com/engine/reference/commandline/login/) command.\n\n### Example: Defining credentials for a container registry\n\n```yaml\ncontainer:\n  image: ghcr.io/owner/image\n  credentials:\n     username: ${{ github.actor }}\n     password: ${{ secrets.github_token }}\n```\n\n## `jobs.<job_id>.container.env`\n\nUse `jobs.<job_id>.container.env` to set a `map` of environment variables in the container.\n\n## `jobs.<job_id>.container.ports`\n\nUse `jobs.<job_id>.container.ports` to set an `array` of ports to expose on the container.\n\n## `jobs.<job_id>.container.volumes`\n\nUse `jobs.<job_id>.container.volumes` to set 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.\n\nTo specify a volume, you specify the source and destination path:\n\n`<source>:<destinationPath>`.\n\nThe `<source>` is a volume name or an absolute path on the host machine, and `<destinationPath>` is an absolute path in the container.\n\n### Example: Mounting volumes in a container\n\n```yaml\nvolumes:\n  - my_docker_volume:/volume_mount\n  - /data/my_data\n  - /source/directory:/destination/directory\n```\n\n## `jobs.<job_id>.container.options`\n\nUse `jobs.<job_id>.container.options` to configure additional Docker container resource options. For a list of options, see [`docker create` options](https://docs.docker.com/engine/reference/commandline/create/#options).\n\n> \\[!WARNING]\n> The `--network` and `--entrypoint` options are not supported.\n\n## `jobs.<job_id>.services`\n\n> \\[!NOTE]\n> If your workflows use Docker container actions, job containers, or service containers, then you must use a Linux runner:\n>\n> * If you are using GitHub-hosted runners, you must use an Ubuntu runner.\n> * If you are using self-hosted runners, you must use a Linux machine as your runner and Docker must be installed.\n\nUsed to host service containers for a job in a workflow. Service containers are useful for creating databases or cache services like Redis. The runner automatically creates a Docker network and manages the life cycle of the service containers.\n\nIf you configure your job to run in a container, or your step uses container actions, you don't need to map ports to access the service or action. Docker automatically exposes all ports between containers on the same Docker user-defined bridge network. You can directly reference the service container by its hostname. The hostname is automatically mapped to the label name you configure for the service in the workflow.\n\nIf you configure the job to run directly on the runner machine and your step doesn't use a container action, you must map any required Docker service container ports to the Docker host (the runner machine). You can access the service container using localhost and the mapped port.\n\nFor more information about the differences between networking service containers, see [Communicating with Docker service containers](/en/enterprise-cloud@latest/actions/using-containerized-services/about-service-containers).\n\n### Example: Using localhost\n\nThis example creates two services: nginx and redis. When you specify the container port but not the host port, the container port is randomly assigned to a free port on the host. GitHub sets the assigned host port in the `${{job.services.<service_name>.ports}}` context. In this example, you can access the service host ports using the `${{ job.services.nginx.ports['80'] }}` and `${{ job.services.redis.ports['6379'] }}` contexts.\n\n```yaml\nservices:\n  nginx:\n    image: nginx\n    # Map port 8080 on the Docker host to port 80 on the nginx container\n    ports:\n      - 8080:80\n  redis:\n    image: redis\n    # Map random free TCP port on Docker host to port 6379 on redis container\n    ports:\n      - 6379/tcp\nsteps:\n  - run: |\n      echo \"Redis available on 127.0.0.1:${{ job.services.redis.ports['6379'] }}\"\n      echo \"Nginx available on 127.0.0.1:${{ job.services.nginx.ports['80'] }}\"\n```\n\n## `jobs.<job_id>.services.<service_id>.image`\n\nThe Docker image to use as the service container to run the action. The value can be the Docker Hub image name or a registry name.\n\nIf `jobs.<job_id>.services.<service_id>.image` is assigned an empty string, the service will not start. You can use this to set up conditional services, similar to the following example.\n\n```yaml\nservices:\n  nginx:\n    image: ${{ options.nginx == true && 'nginx' || '' }}\n```\n\n## `jobs.<job_id>.services.<service_id>.credentials`\n\nIf the image's container registry requires authentication to pull the image, you can use `jobs.<job_id>.container.credentials` to set a `map` of the `username` and `password`. The credentials are the same values that you would provide to the [`docker login`](https://docs.docker.com/engine/reference/commandline/login/) command.\n\n### Example of `jobs.<job_id>.services.<service_id>.credentials`\n\n```yaml\nservices:\n  myservice1:\n    image: ghcr.io/owner/myservice1\n    credentials:\n      username: ${{ github.actor }}\n      password: ${{ secrets.github_token }}\n  myservice2:\n    image: dockerhub_org/myservice2\n    credentials:\n      username: ${{ secrets.DOCKER_USER }}\n      password: ${{ secrets.DOCKER_PASSWORD }}\n```\n\n## `jobs.<job_id>.services.<service_id>.env`\n\nSets a `map` of environment variables in the service container.\n\n## `jobs.<job_id>.services.<service_id>.ports`\n\nSets an `array` of ports to expose on the service container.\n\n## `jobs.<job_id>.services.<service_id>.volumes`\n\nSets 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.\n\nTo specify a volume, you specify the source and destination path:\n\n`<source>:<destinationPath>`.\n\nThe `<source>` is a volume name or an absolute path on the host machine, and `<destinationPath>` is an absolute path in the container.\n\n### Example of `jobs.<job_id>.services.<service_id>.volumes`\n\n```yaml\nvolumes:\n  - my_docker_volume:/volume_mount\n  - /data/my_data\n  - /source/directory:/destination/directory\n```\n\n## `jobs.<job_id>.services.<service_id>.options`\n\nAdditional Docker container resource options. For a list of options, see [`docker create` options](https://docs.docker.com/engine/reference/commandline/create/#options).\n\n> \\[!WARNING]\n> The `--network` option is not supported.\n\n## `jobs.<job_id>.services.<service_id>.command`\n\nOverrides the Docker image's default command (`CMD`). The value is passed as arguments after the image name in the `docker create` command. If you also specify `entrypoint`, `command` provides the arguments to that entrypoint.\n\n### Example of `jobs.<job_id>.services.<service_id>.command`\n\n```yaml\nservices:\n  mysql:\n    image: mysql:8\n    command: --sql_mode=STRICT_TRANS_TABLES --max_allowed_packet=512M\n    env:\n      MYSQL_ROOT_PASSWORD: test\n    ports:\n      - 3306:3306\n```\n\n## `jobs.<job_id>.services.<service_id>.entrypoint`\n\nOverrides the Docker image's default `ENTRYPOINT`. The value is a single string defining the executable to run. Use this when you need to replace the image's entrypoint entirely. You can combine `entrypoint` with `command` to pass arguments to the custom entrypoint.\n\n### Example of `jobs.<job_id>.services.<service_id>.entrypoint`\n\n```yaml\nservices:\n  etcd:\n    image: quay.io/coreos/etcd:v3.5.17\n    entrypoint: etcd\n    command: >-\n      --listen-client-urls http://0.0.0.0:2379\n      --advertise-client-urls http://0.0.0.0:2379\n    ports:\n      - 2379:2379\n```\n\n## `jobs.<job_id>.uses`\n\nThe location and version of a reusable workflow file to run as a job. Use one of the following syntaxes:\n\n* `{owner}/{repo}/.github/workflows/{filename}@{ref}` for reusable workflows in public, internal and private repositories.\n* `./.github/workflows/{filename}` for reusable workflows in the same repository.\n\nIn the first option, `{ref}` can be a SHA, a release tag, or a branch name. If a release tag and a branch have the same name, the release tag takes precedence over the branch name. Using the commit SHA is the safest option for stability and security. For more information, see [Secure use reference](/en/enterprise-cloud@latest/actions/security-guides/security-hardening-for-github-actions#reusing-third-party-workflows).\n\nIf you use the second syntax option (without `{owner}/{repo}` and `@{ref}`) the called workflow is from the same commit as the caller workflow. Ref prefixes such as `refs/heads` and `refs/tags` are not allowed. You cannot use contexts or expressions in this keyword.\n\n### Example of `jobs.<job_id>.uses`\n\n```yaml\njobs:\n  call-workflow-1-in-local-repo:\n    uses: octo-org/this-repo/.github/workflows/workflow-1.yml@172239021f7ba04fe7327647b213799853a9eb89\n  call-workflow-2-in-local-repo:\n    uses: ./.github/workflows/workflow-2.yml\n  call-workflow-in-another-repo:\n    uses: octo-org/another-repo/.github/workflows/workflow.yml@v1\n```\n\nFor more information, see [Reuse workflows](/en/enterprise-cloud@latest/actions/using-workflows/reusing-workflows).\n\n## `jobs.<job_id>.with`\n\nWhen a job is used to call a reusable workflow, you can use `with` to provide a map of inputs that are passed to the called workflow.\n\nAny inputs that you pass must match the input specifications defined in the called workflow.\n\nUnlike [`jobs.<job_id>.steps[*].with`](#jobsjob_idstepswith), the inputs you pass with `jobs.<job_id>.with` are not available as environment variables in the called workflow. Instead, you can reference the inputs by using the `inputs` context.\n\n### Example of `jobs.<job_id>.with`\n\n```yaml\njobs:\n  call-workflow:\n    uses: octo-org/example-repo/.github/workflows/called-workflow.yml@main\n    with:\n      username: mona\n```\n\n## `jobs.<job_id>.with.<input_id>`\n\nA pair consisting of a string identifier for the input and the value of the input. The identifier must match the name of an input defined by [`on.workflow_call.inputs.<inputs_id>`](/en/enterprise-cloud@latest/actions/creating-actions/metadata-syntax-for-github-actions#inputsinput_id) in the called workflow. The data type of the value must match the type defined by [`on.workflow_call.inputs.<input_id>.type`](#onworkflow_callinputsinput_idtype) in the called workflow.\n\nAllowed expression contexts: `github`, and `needs`.\n\n## `jobs.<job_id>.secrets`\n\nWhen a job is used to call a reusable workflow, you can use `secrets` to provide a map of secrets that are passed to the called workflow.\n\nAny secrets that you pass must match the names defined in the called workflow.\n\n### Example of `jobs.<job_id>.secrets`\n\n```yaml\njobs:\n  call-workflow:\n    uses: octo-org/example-repo/.github/workflows/called-workflow.yml@main\n    secrets:\n      access-token: ${{ secrets.PERSONAL_ACCESS_TOKEN }}\n```\n\n## `jobs.<job_id>.secrets.inherit`\n\nUse 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.\n\n### Example of `jobs.<job_id>.secrets.inherit`\n\n```yaml\non:\n  workflow_dispatch:\n\njobs:\n  pass-secrets-to-workflow:\n    uses: ./.github/workflows/called-workflow.yml\n    secrets: inherit\n```\n\n```yaml\non:\n  workflow_call:\n\njobs:\n  pass-secret-to-action:\n    runs-on: ubuntu-latest\n    steps:\n      - name: Use a repo or org secret from the calling workflow.\n        run: echo ${{ secrets.CALLING_WORKFLOW_SECRET }}\n```\n\n## `jobs.<job_id>.secrets.<secret_id>`\n\nA pair consisting of a string identifier for the secret and the value of the secret. The identifier must match the name of a secret defined by [`on.workflow_call.secrets.<secret_id>`](#onworkflow_callsecretssecret_id) in the called workflow.\n\nAllowed expression contexts: `github`, `needs`, and `secrets`.\n\n## Filter pattern cheat sheet\n\nYou can use special characters in path, branch, and tag filters.\n\n* `*`: Matches zero or more characters, but does not match the `/` character. For example, `Octo*` matches `Octocat`.\n* `**`: Matches zero or more of any character.\n* `?`: Matches zero or one of the preceding character.\n* `+`: Matches one or more of the preceding character.\n* `[]` Matches one alphanumeric character listed in the brackets or included in ranges. Ranges can only include `a-z`, `A-Z`, and `0-9`. For example, the range`[0-9a-z]` matches any digit or lowercase letter. For example, `[CB]at` matches `Cat` or `Bat` and `[1-2]00` matches `100` and `200`.\n* `!`: At the start of a pattern makes it negate previous positive patterns. It has no special meaning if not the first character.\n\nThe characters `*`, `[`, and `!` are special characters in YAML. If you start a pattern with `*`, `[`, or `!`, you must enclose the pattern in quotes. Also, if you use a [flow sequence](https://yaml.org/spec/1.2.2/#flow-sequences) with a pattern containing `[` and/or `]`, the pattern must be enclosed in quotes.\n\n```yaml\n# Valid\npaths:\n  - '**/README.md'\n\n# Invalid - creates a parse error that\n# prevents your workflow from running.\npaths:\n  - **/README.md\n\n# Valid\nbranches: [ main, 'release/v[0-9].[0-9]' ]\n\n# Invalid - creates a parse error\nbranches: [ main, release/v[0-9].[0-9] ]\n```\n\nFor more information about branch, tag, and path filter syntax, see [`on.<push>.<branches|tags>`](#onpushbranchestagsbranches-ignoretags-ignore), [`on.<pull_request>.<branches|tags>`](#onpull_requestpull_request_targetbranchesbranches-ignore), and [`on.<push|pull_request>.paths`](#onpushpull_requestpull_request_targetpathspaths-ignore).\n\n### Patterns to match branches and tags\n\n| Pattern                                     | Description                                                                                                                                                                  | Example matches                                                                               |\n| ------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------- |\n| `feature/*`                                 | The `*` wildcard matches any character, but does not match slash (`/`).                                                                                                      | `feature/my-branch`<br/><br/>`feature/your-branch`                                            |\n| `feature/**`                                | The `**` wildcard matches any character including slash (`/`) in branch and tag names.                                                                                       | `feature/beta-a/my-branch`<br/><br/>`feature/your-branch`<br/><br/>`feature/mona/the/octocat` |\n| `main`<br/><br/>`releases/mona-the-octocat` | Matches the exact name of a branch or tag name.                                                                                                                              | `main`<br/><br/>`releases/mona-the-octocat`                                                   |\n| `'*'`                                       | Matches all branch and tag names that don't contain a slash (`/`). The `*` character is a special character in YAML. When you start a pattern with `*`, you must use quotes. | `main`<br/><br/>`releases`                                                                    |\n| `'**'`                                      | Matches all branch and tag names. This is the default behavior when you don't use a `branches` or `tags` filter.                                                             | `all/the/branches`<br/><br/>`every/tag`                                                       |\n| `'*feature'`                                | The `*` character is a special character in YAML. When you start a pattern with `*`, you must use quotes.                                                                    | `mona-feature`<br/><br/>`feature`<br/><br/>`ver-10-feature`                                   |\n| `v2*`                                       | Matches branch and tag names that start with `v2`.                                                                                                                           | `v2`<br/><br/>`v2.0`<br/><br/>`v2.9`                                                          |\n| `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`                                                                   |\n\n### Patterns to match file paths\n\nPath patterns must match the whole path, and start from the repository's root.\n\n| Pattern                                             | Description of matches                                                                                                                                                                        | Example matches                                                                         |\n| --------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------- |\n| `'*'`                                               | The `*` wildcard matches any character, but does not match slash (`/`). The `*` character is a special character in YAML. When you start a pattern with `*`, you must use quotes.             | `README.md`<br/><br/>`server.rb`                                                        |\n| `'*.jsx?'`                                          | The `?` character matches zero or one of the preceding character.                                                                                                                             | `page.js`<br/><br/>`page.jsx`                                                           |\n| `'**'`                                              | The `**` wildcard matches any character including slash (`/`). This is the default behavior when you don't use a `path` filter.                                                               | `all/the/files.md`                                                                      |\n| `'*.js'`                                            | The `*` wildcard matches any character, but does not match slash (`/`). Matches all `.js` files at the root of the repository.                                                                | `app.js`<br/><br/>`index.js`                                                            |\n| `'**.js'`                                           | Matches all `.js` files in the repository.                                                                                                                                                    | `index.js`<br/><br/>`js/index.js`<br/><br/>`src/js/app.js`                              |\n| `docs/*`                                            | All files within the root of the `docs` directory only, at the root of the repository.                                                                                                        | `docs/README.md`<br/><br/>`docs/file.txt`                                               |\n| `docs/**`                                           | Any files in the `docs` directory and its subdirectories at the root of the repository.                                                                                                       | `docs/README.md`<br/><br/>`docs/mona/octocat.txt`                                       |\n| `docs/**/*.md`                                      | A file with a `.md` suffix anywhere in the `docs` directory.                                                                                                                                  | `docs/README.md`<br/><br/>`docs/mona/hello-world.md`<br/><br/>`docs/a/markdown/file.md` |\n| `'**/docs/**'`                                      | Any files in a `docs` directory anywhere in the repository.                                                                                                                                   | `docs/hello.md`<br/><br/>`dir/docs/my-file.txt`<br/><br/>`space/docs/plan/space.doc`    |\n| `'**/README.md'`                                    | A README.md file anywhere in the repository.                                                                                                                                                  | `README.md`<br/><br/>`js/README.md`                                                     |\n| `'**/*src/**'`                                      | Any file in a folder with a `src` suffix anywhere in the repository.                                                                                                                          | `a/src/app.js`<br/><br/>`my-src/code/js/app.js`                                         |\n| `'**/*-post.md'`                                    | A file with the suffix `-post.md` anywhere in the repository.                                                                                                                                 | `my-post.md`<br/><br/>`path/their-post.md`                                              |\n| `'**/migrate-*.sql'`                                | A file with the prefix `migrate-` and suffix `.sql` anywhere in the repository.                                                                                                               | `migrate-10909.sql`<br/><br/>`db/migrate-v1.0.sql`<br/><br/>`db/sept/migrate-v1.sql`    |\n| `'*.md'`<br/><br/>`'!README.md'`                    | Using an exclamation mark (`!`) in front of a pattern negates it. When a file matches a pattern and also matches a negative pattern defined later in the file, the file will not be included. | `hello.md`<br/><br/>*Does not match*<br/><br/>`README.md`<br/><br/>`docs/hello.md`      |\n| `'*.md'`<br/><br/>`'!README.md'`<br/><br/>`README*` | Patterns are checked sequentially. A pattern that negates a previous pattern will re-include file paths.                                                                                      | `hello.md`<br/><br/>`README.md`<br/><br/>`README.doc`                                   |"}