{"meta":{"title":"Triggering a workflow","intro":"How to automatically trigger GitHub Actions workflows","product":"GitHub Actions","breadcrumbs":[{"href":"/en/actions","title":"GitHub Actions"},{"href":"/en/actions/how-tos","title":"How-tos"},{"href":"/en/actions/how-tos/write-workflows","title":"Write workflows"},{"href":"/en/actions/how-tos/write-workflows/choose-when-workflows-run","title":"Choose when workflows run"},{"href":"/en/actions/how-tos/write-workflows/choose-when-workflows-run/trigger-a-workflow","title":"Trigger a workflow"}],"documentType":"article"},"body":"# Triggering a workflow\n\nHow to automatically trigger GitHub Actions workflows\n\n## Prerequisites\n\nTo learn more about workflows and triggering workflows, see [Workflows](/en/actions/concepts/workflows-and-actions/workflows).\n\n## Triggering a workflow from a workflow\n\nWhen you use the repository's `GITHUB_TOKEN` to perform tasks, events triggered by the `GITHUB_TOKEN` will not create a new workflow run, with the following exceptions:\n\n* `workflow_dispatch` and `repository_dispatch` events always create workflow runs.\n* `pull_request` events with the `opened`, `synchronize`, or `reopened` activity types: when a workflow using `GITHUB_TOKEN` creates or updates a pull request, the resulting `pull_request` event creates workflow runs in an **approval-required** state. The pull request displays a banner in the merge box, and a user with write access to the repository can start the runs by selecting **Approve workflows to run**. Other `pull_request` activity types (such as `labeled`, `edited`, or `closed`) do not create workflow runs. This prevents recursive workflow runs while still allowing CI workflows to run on pull requests created by automation. For more information about approving workflow runs, see [Approving workflow runs from forks](/en/actions/how-tos/manage-workflow-runs/approve-runs-from-forks).\n\nFor all other events, this behavior prevents you from accidentally creating recursive workflow runs. For example, if a workflow run pushes code using the repository's `GITHUB_TOKEN`, a new workflow will not run even when the repository contains a workflow configured to run when `push` events occur. For more information, see [Use GITHUB\\_TOKEN for authentication in workflows](/en/actions/tutorials/authenticate-with-github_token).\n\nIf you do want to trigger a workflow from within a workflow run, you can use a GitHub App installation access token or a personal access token instead of `GITHUB_TOKEN` to trigger events that require a token. Using one of these alternatives also lets `pull_request` workflows run automatically (without the approval prompt described above) when the pull request is created or updated by automation.\n\nIf you use a GitHub App, you'll need to create a GitHub App and store the app ID and private key as secrets. For more information, see [Making authenticated API requests with a GitHub App in a GitHub Actions workflow](/en/apps/creating-github-apps/authenticating-with-a-github-app/making-authenticated-api-requests-with-a-github-app-in-a-github-actions-workflow). If you use a personal access token, you'll need to create a personal access token and store it as a secret. For more information about creating a personal access token, see [Managing your personal access tokens](/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens). For more information about storing secrets, see [Using secrets in GitHub Actions](/en/actions/how-tos/write-workflows/choose-what-workflows-do/use-secrets).\n\nTo minimize your GitHub Actions usage costs, ensure that you don't create recursive or unintended workflow runs.\n\nFor example, the following workflow uses a personal access token (stored as a secret called `MY_TOKEN`) to add a label to an issue via GitHub CLI. Any workflows that run when a label is added will run once this step is performed.\n\n```yaml\non:\n  issues:\n    types:\n      - opened\n\njobs:\n  label_issue:\n    runs-on: ubuntu-latest\n    steps:\n      - env:\n          GH_TOKEN: ${{ secrets.MY_TOKEN }}\n          ISSUE_URL: ${{ github.event.issue.html_url }}\n        run: |\n          gh issue edit $ISSUE_URL --add-label \"triage\"\n```\n\nConversely, the following workflow uses `GITHUB_TOKEN` to add a label to an issue. It will not trigger any workflows that run when a label is added.\n\n```yaml\non:\n  issues:\n    types:\n      - opened\n\njobs:\n  label_issue:\n    runs-on: ubuntu-latest\n    steps:\n      - env:\n          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}\n          ISSUE_URL: ${{ github.event.issue.html_url }}\n        run: |\n          gh issue edit $ISSUE_URL --add-label \"triage\"\n```\n\n## Using events to trigger workflows\n\nUse the `on` key to specify what events trigger your workflow. For more information about events you can use, see [Events that trigger workflows](/en/actions/reference/workflows-and-actions/events-that-trigger-workflows).\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 and filters with multiple events\n\nYou can use activity types and filters to further control when your workflow will run. For more information, see [Using event activity types](#using-event-activity-types) and [Using filters](#using-filters). If 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## Using event 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/actions/reference/workflows-and-actions/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 filters to target specific branches for pull request events\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/actions/reference/workflows-and-actions/workflow-syntax#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/actions/reference/workflows-and-actions/workflow-syntax#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\nIf a workflow is skipped due to branch filtering, [path filtering](/en/actions/reference/workflows-and-actions/workflow-syntax#onpushpull_requestpull_request_targetpathspaths-ignore), or a [commit message](/en/actions/how-tos/manage-workflow-runs/skip-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### Using filters to target specific branches or tags for push events\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/actions/reference/workflows-and-actions/workflow-syntax#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/actions/reference/workflows-and-actions/workflow-syntax#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### Using filters to target specific paths for pull request or push events\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/actions/reference/workflows-and-actions/workflow-syntax#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\nIf a workflow is skipped due to path filtering, [branch filtering](/en/actions/reference/workflows-and-actions/workflow-syntax#onpull_requestpull_request_targetbranchesbranches-ignore), or a [commit message](/en/actions/how-tos/manage-workflow-runs/skip-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\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\nIn some situations, GitHub Actions applies limits that change how filtered workflows run:\n\n* If a push contains more than 1,000 commits, the workflow will **always** run.\n* If generating the diff times out, the workflow will **always** run.\n* If the generated diff contains more than 3,000 files and the files the workflow filter matches are not in the first 3,000 returned by the filter, the workflow will **not** run.\n\nIf you observe these behaviors, you might need to make your filters more specific, or change how you work with pushes and pull requests to generate simpler diffs.\n\nFor more information, see [Branches](/en/pull-requests/reference/branches).\n\n### Using filters to target specific branches for workflow run events\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/actions/reference/workflows-and-actions/workflow-syntax#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## Defining inputs for manually triggered workflows\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.\nThe triggered workflow receives the inputs in the `inputs` context. For more information, see [Contexts](/en/actions/reference/workflows-and-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```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## Defining inputs, outputs, and secrets for reusable workflows\n\nYou can define inputs and secrets that a reusable workflow should receive from a calling workflow. You can also specify outputs that a reusable workflow will make available to a calling workflow. For more information, see [Reuse workflows](/en/actions/how-tos/reuse-automations/reuse-workflows).\n\n## Using event information\n\nInformation about the event that triggered a workflow run is available in the `github.event` context. The properties in the `github.event` context depend on the type of event that triggered the workflow. For example, a workflow triggered when an issue is labeled would have information about the issue and label.\n\n### Viewing all properties of an event\n\nReference the webhook event documentation for common properties and example payloads. For more information, see [Webhook events and payloads](/en/webhooks/webhook-events-and-payloads).\n\nYou can also print the entire `github.event` context to see what properties are available for the event that triggered your workflow:\n\n```yaml\njobs:\n  print_context:\n    runs-on: ubuntu-latest\n    steps:\n      - env:\n          EVENT_CONTEXT: ${{ toJSON(github.event) }}\n        run: |\n          echo $EVENT_CONTEXT\n```\n\n### Accessing and using event properties\n\nYou can use the `github.event` context in your workflow. For example, the following workflow runs when a pull request that changes `package*.json`, `.github/CODEOWNERS`, or `.github/workflows/**` is opened. If the pull request author (`github.event.pull_request.user.login`) is not `octobot` or `dependabot[bot]`, then the workflow uses the GitHub CLI to label and comment on the pull request (`github.event.pull_request.number`).\n\n```yaml\non:\n  pull_request:\n    types:\n      - opened\n    paths:\n      - '.github/workflows/**'\n      - '.github/CODEOWNERS'\n      - 'package*.json'\n\njobs:\n  triage:\n    if: >-\n      github.event.pull_request.user.login != 'octobot' &&\n      github.event.pull_request.user.login != 'dependabot[bot]'\n    runs-on: ubuntu-latest\n    steps:\n      - name: \"Comment about changes we can't accept\"\n        env:\n          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}\n          PR: ${{ github.event.pull_request.html_url }}\n        run: |\n          gh pr edit $PR --add-label 'invalid'\n          gh pr comment $PR --body 'It looks like you edited `package*.json`, `.github/CODEOWNERS`, or `.github/workflows/**`. We do not allow contributions to these files. Please review our [contributing guidelines](https://github.com/octo-org/octo-repo/blob/main/CONTRIBUTING.md) for what contributions are accepted.'\n```\n\nFor more information about contexts, see [Contexts reference](/en/actions/reference/workflows-and-actions/contexts). For more information about event payloads, see [Webhook events and payloads](/en/webhooks/webhook-events-and-payloads).\n\n## Further controlling how your workflow will run\n\nIf you want more granular control than events, event activity types, or event filters provide, you can use conditionals and environments to control whether individual jobs or steps in your workflow will run.\n\n### Using conditionals\n\nYou can use conditionals to further control whether jobs or steps in your workflow will run.\n\n#### Example using a value in the event payload\n\nFor example, if you want the workflow to run when a specific label is added to an issue, you can trigger on the `issues labeled` event activity type and use a conditional to check what label triggered the workflow. The following workflow will run when any label is added to an issue in the workflow's repository, but the `run_if_label_matches` job will only execute if the label is named `bug`.\n\n```yaml\non:\n  issues:\n    types:\n      - labeled\n\njobs:\n  run_if_label_matches:\n    if: github.event.label.name == 'bug'\n    runs-on: ubuntu-latest\n    steps:\n      - run: echo 'The label was bug'\n```\n\n#### Example using event type\n\nFor example, if you want to run different jobs or steps depending on what event triggered the workflow, you can use a conditional to check whether a specific event type exists in the event context. The following workflow will run whenever an issue or pull request is closed. If the workflow ran because an issue was closed, the `github.event` context will contain a value for `issue` but not for `pull_request`. Therefore, the `if_issue` step will run but the `if_pr` step will not run. Conversely, if the workflow ran because a pull request was closed, the `if_pr` step will run but the `if_issue` step will not run.\n\n```yaml\non:\n  issues:\n    types:\n      - closed\n  pull_request:\n    types:\n      - closed\n\njobs:\n  state_event_type:\n    runs-on: ubuntu-latest\n    steps:\n    - name: if_issue\n      if: github.event.issue\n      run: |\n        echo An issue was closed\n    - name: if_pr\n      if: github.event.pull_request\n      run: |\n        echo A pull request was closed\n```\n\nFor more information about what information is available in the event context, see [Using event information](#using-event-information). For more information about how to use conditionals, see [Evaluate expressions in workflows and actions](/en/actions/reference/workflows-and-actions/expressions).\n\n### Using environments to manually trigger workflow jobs\n\nIf you want to manually trigger a specific job in a workflow, you can use an environment that requires approval from a specific team or user. First, configure an environment with required reviewers. For more information, see [Managing environments for deployment](/en/actions/how-tos/deploy/configure-and-manage-deployments/manage-environments). Then, reference the environment name in a job in your workflow using the `environment:` key. Any job referencing the environment will not run until at least one reviewer approves the job.\n\nFor example, the following workflow will run whenever there is a push to main. The `build` job will always run. The `publish` job will only run after the `build` job successfully completes (due to `needs: [build]`) and after all of the rules (including required reviewers) for the environment called `production` pass (due to `environment: production`).\n\n```yaml\non:\n  push:\n    branches:\n      - main\n\njobs:\n  build:\n    runs-on: ubuntu-latest\n    steps:\n      - name: build\n        run: |\n          echo 'building'\n\n  publish:\n    needs: [build]\n    runs-on: ubuntu-latest\n    environment: production\n    steps:\n      - name: publish\n        run: |\n          echo 'publishing'\n```\n\n> \\[!NOTE]\n> Environments, environment secrets, and deployment protection rules are available in public repositories for all current GitHub plans. They are not available on legacy plans, such as Bronze, Silver, or Gold. For access to environments, environment secrets, and deployment branches in private or internal repositories, you must use GitHub Pro, GitHub Team, or GitHub Enterprise. If you are on a GitHub Free, GitHub Pro, or GitHub Team plan, other deployment protection rules, such as a wait timer or required reviewers, are only available for public repositories.\n\n## Available events\n\nFor a full list of available events, see [Events that trigger workflows](/en/actions/reference/workflows-and-actions/events-that-trigger-workflows)."}