About events that trigger workflows

Workflow triggers are events that cause a workflow to run. For more information about how to use workflow triggers, seeTriggering a workflow.

Some events have multiple activity types. For these events, you can specify which activity types will trigger a workflow run. For more information about what each activity type means, seeWebhook events and payloads.

branch_protection_rule

Runs your workflow when branch protection rules in the workflow repository are changed. For more information about branch protection rules, seeAbout protected branches. For information about the branch protection rule APIs, seeObjects in the GraphQL API documentation orREST API endpoints for branches and their settings.

For example, you can run a workflow when a branch protection rule has beencreated ordeleted:

on:branch_protection_rule:types: [created,deleted]

check_run

Runs your workflow when activity related to a check run occurs. A check run is an individual test that is part of a check suite. For information, seeUsing the REST API to interact with checks. For information about the check run APIs, seeObjects in the GraphQL API documentation orREST API endpoints for check runs.

For example, you can run a workflow when a check run has beenrerequested orcompleted.

on:check_run:types: [rerequested,completed]

check_suite

Runs your workflow when check suite activity occurs. A check suite is a collection of the check runs created for a specific commit. Check suites summarize the status and conclusion of the check runs that are in the suite. For information, seeUsing the REST API to interact with checks. For information about the check suite APIs, seeObjects in the GraphQL API documentation orREST API endpoints for check suites.

For example, you can run a workflow when a check suite has beencompleted.

on:check_suite:types: [completed]

create

Runs your workflow when someone creates a Git reference (Git branch or tag) in the workflow's repository. For information about the APIs to create a Git reference, seeMutations in the GraphQL API documentation orREST API endpoints for Git references.

For example, you can run a workflow when thecreate event occurs.

on:create

delete

Runs your workflow when someone deletes a Git reference (Git branch or tag) in the workflow's repository. For information about the APIs to delete a Git reference, seeMutations in the GraphQL API documentation orREST API endpoints for Git references.

For example, you can run a workflow when thedelete event occurs.

on:delete

deployment

Runs your workflow when someone creates a deployment in the workflow's repository. Deployments created with a commit SHA may not have a Git ref. For information about the APIs to create a deployment, seeMutations in the GraphQL API documentation orREST API endpoints for repositories.

For example, you can run a workflow when thedeployment event occurs.

on:deployment

deployment_status

Runs your workflow when a third party provides a deployment status. Deployments created with a commit SHA may not have a Git ref. For information about the APIs to create a deployment status, seeMutations in the GraphQL API documentation orREST API endpoints for deployments.

For example, you can run a workflow when thedeployment_status event occurs.

on:deployment_status

discussion

Runs your workflow when a discussion in the workflow's repository is created or modified. For activity related to comments on a discussion, use thediscussion_comment event. For more information about discussions, seeAbout discussions. For information about the GraphQL API, seeObjects.

For example, you can run a workflow when a discussion has beencreated,edited, oranswered.

on:discussion:types: [created,edited,answered]

discussion_comment

Runs your workflow when a comment on a discussion in the workflow's repository is created or modified. For activity related to a discussion as opposed to comments on the discussion, use thediscussion event. For more information about discussions, seeAbout discussions. For information about the GraphQL API, seeObjects.

For example, you can run a workflow when a discussion comment has beencreated ordeleted.

on:discussion_comment:types: [created,deleted]

fork

Runs your workflow when someone forks a repository. For information about the REST API, seeREST API endpoints for forks.

For example, you can run a workflow when thefork event occurs.

on:fork

gollum

Runs your workflow when someone creates or updates a Wiki page. For more information, seeAbout wikis.

For example, you can run a workflow when thegollum event occurs.

on:gollum

issue_comment

Runs your workflow when an issue or pull request comment is created, edited, or deleted. For information about the issue comment APIs, seeObjects in the GraphQL API documentation orWebhook events and payloads in the REST API documentation.

For example, you can run a workflow when an issue or pull request comment has beencreated ordeleted.

on:issue_comment:types: [created,deleted]

issue_comment on issues only or pull requests only

Theissue_comment event occurs for comments on both issues and pull requests. You can use thegithub.event.issue.pull_request property in a conditional to take different action depending on whether the triggering object was an issue or pull request.

For example, this workflow will run thepr_commented job only if theissue_comment event originated from a pull request. It will run theissue_commented job only if theissue_comment event originated from an issue.

on:issue_commentjobs:pr_commented:# This job only runs for pull request commentsname:PRcommentif:${{github.event.issue.pull_request}}runs-on:ubuntu-lateststeps:-run:|          echo A comment on PR $NUMBERenv:NUMBER:${{github.event.issue.number}}issue_commented:# This job only runs for issue commentsname:Issuecommentif:${{!github.event.issue.pull_request}}runs-on:ubuntu-lateststeps:-run:|          echo A comment on issue $NUMBERenv:NUMBER:${{github.event.issue.number}}

issues

Runs your workflow when an issue in the workflow's repository is created or modified. For activity related to comments in an issue, use theissue_comment event. For more information about issues, seeAbout issues. For information about the issue APIs, seeObjects in the GraphQL API documentation orREST API endpoints for issues.

For example, you can run a workflow when an issue has beenopened,edited, ormilestoned.

on:issues:types: [opened,edited,milestoned]

label

Runs your workflow when a label in your workflow's repository is created or modified. For more information about labels, seeManaging labels. For information about the label APIs, seeObjects in the GraphQL API documentation orREST API endpoints for labels.

If you want to run your workflow when a label is added to or removed from an issue, pull request, or discussion, use thelabeled orunlabeled activity types for theissues,pull_request,pull_request_target, ordiscussion events instead.

For example, you can run a workflow when a label has beencreated ordeleted.

on:label:types: [created,deleted]

merge_group

Runs your workflow when a pull request is added to a merge queue, which adds the pull request to a merge group. For more information seeMerging a pull request with a merge queue.

For example, you can run a workflow when thechecks_requested activity has occurred.

on:pull_request:branches: ["main" ]merge_group:types: [checks_requested]

milestone

Runs your workflow when a milestone in the workflow's repository is created or modified. For more information about milestones, seeAbout milestones. For information about the milestone APIs, seeObjects in the GraphQL API documentation orREST API endpoints for milestones.

If you want to run your workflow when an issue is added to or removed from a milestone, use themilestoned ordemilestoned activity types for theissues event instead.

For example, you can run a workflow when a milestone has beenopened ordeleted.

on:milestone:types: [opened,deleted]

page_build

Runs your workflow when someone pushes to a branch that is the publishing source for GitHub Pages, if GitHub Pages is enabled for the repository. For more information about GitHub Pages publishing sources, seeConfiguring a publishing source for your GitHub Pages site. For information about the REST API, seeREST API endpoints for repositories.

For example, you can run a workflow when thepage_build event occurs.

on:page_build

public

Runs your workflow when your workflow's repository changes from private to public. For information about the REST API, seeREST API endpoints for repositories.

For example, you can run a workflow when thepublic event occurs.

on:public

pull_request

Runs your workflow when activity on a pull request in the workflow's repository occurs. For example, if no activity types are specified, the workflow runs when a pull request is opened or reopened or when the head branch of the pull request is updated. For activity related to pull request reviews, pull request review comments, or pull request comments, use thepull_request_review,pull_request_review_comment, orissue_comment events instead. For information about the pull request APIs, seeObjects in the GraphQL API documentation orREST API endpoints for pull requests.

Note thatGITHUB_SHA for this event is the last merge commit of the pull request merge branch. If you want to get the commit ID for the last commit to the head branch of the pull request, usegithub.event.pull_request.head.sha instead.

For example, you can run a workflow when a pull request has been opened or reopened.

on:pull_request:types: [opened,reopened]

You can use the event context to further control when jobs in your workflow will run. For example, this workflow will run when a review is requested on a pull request, but thespecific_review_requested job will only run when a review byocto-team is requested.

on:pull_request:types: [review_requested]jobs:specific_review_requested:runs-on:ubuntu-latestif:${{github.event.requested_team.name=='octo-team'}}steps:-run:echo'A review from octo-team was requested'

Running yourpull_request workflow based on the head or base branch of a pull request

You can use thebranches orbranches-ignore filter to configure your workflow to only run on pull requests that target specific branches. For more information, seeWorkflow syntax for GitHub Actions.

For example, this workflow will run when someone opens a pull request that targets a branch whose name starts withreleases/:

on:pull_request:types:-openedbranches:-'releases/**'

on:pull_request:types:-openedbranches:-'releases/**'paths:-'**.js'

To run a job based on the pull request's head branch name (as opposed to the pull request's base branch name), use thegithub.head_ref context in a conditional. For example, this workflow will run whenever a pull request is opened, but therun_if job will only execute if the head of the pull request is a branch whose name starts withreleases/:

on:pull_request:types:-openedjobs:run_if:if:startsWith(github.head_ref,'releases/')runs-on:ubuntu-lateststeps:-run:echo"The head of this PR starts with 'releases/'"

Running yourpull_request workflow based on files changed in a pull request

You can also configure your workflow to run when a pull request changes specific files. For more information, seeWorkflow syntax for GitHub Actions.

For example, this workflow will run when a pull request includes a change to a JavaScript file (.js):

on:pull_request:paths:-'**.js'

on:pull_request:types:-openedbranches:-'releases/**'paths:-'**.js'

Running yourpull_request workflow when a pull request merges

When a pull request merges, the pull request is automatically closed. To run a workflow when a pull request merges, use thepull_requestclosed event type along with a conditional that checks themerged value of the event. For example, the following workflow will run whenever a pull request closes. Theif_merged job will only run if the pull request was also merged.

on:pull_request:types:-closedjobs:if_merged:if:github.event.pull_request.merged==trueruns-on:ubuntu-lateststeps:-run:|        echo The PR was merged

Workflows in forked repositories

Workflows don't run in forked repositories by default. You must enable GitHub Actions in theActions tab of the forked repository.

With the exception ofGITHUB_TOKEN, secrets are not passed to the runner when a workflow is triggered from a forked repository. TheGITHUB_TOKEN has read-only permissions in pull requests from forked repositories. For more information, seeUse GITHUB_TOKEN in workflows.

Pull request events for forked repositories

For pull requests from a forked repository to the base repository, GitHub sends thepull_request,issue_comment,pull_request_review_comment,pull_request_review, andpull_request_target events to the base repository. No pull request events occur on the forked repository.

When a first-time contributor submits a pull request to a public repository, a maintainer with write access may need to approve running workflows on the pull request. For more information, seeApproving workflow runs from public forks.

For pull requests from a forked repository to a private repository, workflows only run when they are enabled, seeManaging GitHub Actions settings for a repository.

pull_request_comment (useissue_comment)

To run your workflow when a comment on a pull request (not on a pull request's diff) is created, edited, or deleted, use theissue_comment event. For activity related to pull request reviews or pull request review comments, use thepull_request_review orpull_request_review_comment events.

pull_request_review

Runs your workflow when a pull request review is submitted, edited, or dismissed. A pull request review is a group of pull request review comments in addition to a body comment and a state. For activity related to pull request review comments or pull request comments, use thepull_request_review_comment orissue_comment events instead. For information about the pull request review APIs, seeObjects in the GraphQL API documentation orREST API endpoints for pull requests.

For example, you can run a workflow when a pull request review has beenedited ordismissed.

on:pull_request_review:types: [edited,dismissed]

Running a workflow when a pull request is approved

To run your workflow when a pull request has been approved, you can trigger your workflow with thesubmitted type ofpull_request_review event, then check the review state with thegithub.event.review.state property. For example, this workflow will run whenever a pull request review is submitted, but theapproved job will only run if the submitted review is an approving review:

on:pull_request_review:types: [submitted]jobs:approved:if:github.event.review.state=='approved'runs-on:ubuntu-lateststeps:-run:echo"This PR was approved"

Workflows in forked repositories

Workflows don't run in forked repositories by default. You must enable GitHub Actions in theActions tab of the forked repository.

With the exception ofGITHUB_TOKEN, secrets are not passed to the runner when a workflow is triggered from a forked repository. TheGITHUB_TOKEN has read-only permissions in pull requests from forked repositories. For more information, seeUse GITHUB_TOKEN in workflows.

Pull request events for forked repositories

For pull requests from a forked repository to the base repository, GitHub sends thepull_request,issue_comment,pull_request_review_comment,pull_request_review, andpull_request_target events to the base repository. No pull request events occur on the forked repository.

When a first-time contributor submits a pull request to a public repository, a maintainer with write access may need to approve running workflows on the pull request. For more information, seeApproving workflow runs from public forks.

For pull requests from a forked repository to a private repository, workflows only run when they are enabled, seeManaging GitHub Actions settings for a repository.

pull_request_review_comment

Runs your workflow when a pull request review comment is modified. A pull request review comment is a comment on a pull request's diff. For activity related to pull request reviews or pull request comments, use thepull_request_review orissue_comment events instead. For information about the pull request review comment APIs, seeObjects in the GraphQL API documentation orREST API endpoints for pull requests.

For example, you can run a workflow when a pull request review comment has beencreated ordeleted.

on:pull_request_review_comment:types: [created,deleted]

Workflows in forked repositories

Workflows don't run in forked repositories by default. You must enable GitHub Actions in theActions tab of the forked repository.

With the exception ofGITHUB_TOKEN, secrets are not passed to the runner when a workflow is triggered from a forked repository. TheGITHUB_TOKEN has read-only permissions in pull requests from forked repositories. For more information, seeUse GITHUB_TOKEN in workflows.

Pull request events for forked repositories

For pull requests from a forked repository to the base repository, GitHub sends thepull_request,issue_comment,pull_request_review_comment,pull_request_review, andpull_request_target events to the base repository. No pull request events occur on the forked repository.

When a first-time contributor submits a pull request to a public repository, a maintainer with write access may need to approve running workflows on the pull request. For more information, seeApproving workflow runs from public forks.

For pull requests from a forked repository to a private repository, workflows only run when they are enabled, seeManaging GitHub Actions settings for a repository.

pull_request_target

Runs your workflow when activity on a pull request in the workflow's repository occurs. For example, if no activity types are specified, the workflow runs when a pull request is opened or reopened or when the head branch of the pull request is updated.

This event runs in the context of the base of the pull request, rather than in the context of the merge commit, as thepull_request event does. This prevents execution of unsafe code from the head of the pull request that could alter your repository or steal any secrets you use in your workflow. This event allows your workflow to do things like label or comment on pull requests from forks. Avoid using this event if you need to build or run code from the pull request.

To ensure repository security, branches with names that match certain patterns (such as those which look similar to SHAs) may not trigger workflows with thepull_request_target event.

For example, you can run a workflow when a pull request has beenassigned,opened,synchronize, orreopened.

on:pull_request_target:types: [assigned,opened,synchronize,reopened]

Running yourpull_request_target workflow based on the head or base branch of a pull request

You can use thebranches orbranches-ignore filter to configure your workflow to only run on pull requests that target specific branches. For more information, seeWorkflow syntax for GitHub Actions.

For example, this workflow will run when someone opens a pull request that targets a branch whose name starts withreleases/:

on:pull_request_target:types:-openedbranches:-'releases/**'

on:pull_request_target:types:-openedbranches:-'releases/**'paths:-'**.js'

To run a job based on the pull request's head branch name (as opposed to the pull request's base branch name), use thegithub.head_ref context in a conditional. For example, this workflow will run whenever a pull request is opened, but therun_if job will only execute if the head of the pull request is a branch whose name starts withreleases/:

on:pull_request_target:types:-openedjobs:run_if:if:startsWith(github.head_ref,'releases/')runs-on:ubuntu-lateststeps:-run:echo"The head of this PR starts with 'releases/'"

Running yourpull_request_target workflow based on files changed in a pull request

You can use thepaths orpaths-ignore filter to configure your workflow to run when a pull request changes specific files. For more information, seeWorkflow syntax for GitHub Actions.

For example, this workflow will run when a pull request includes a change to a JavaScript file (.js):

on:pull_request_target:paths:-'**.js'

on:pull_request_target:types:-openedbranches:-'releases/**'paths:-'**.js'

Running yourpull_request_target workflow when a pull request merges

When a pull request merges, the pull request is automatically closed. To run a workflow when a pull request merges, use thepull_request_targetclosed event type along with a conditional that checks themerged value of the event. For example, the following workflow will run whenever a pull request closes. Theif_merged job will only run if the pull request was also merged.

on:pull_request_target:types:-closedjobs:if_merged:if:github.event.pull_request.merged==trueruns-on:ubuntu-lateststeps:-run:|        echo The PR was merged

push

Runs your workflow when you push a commit or tag, or when you create a repository from a template.

For example, you can run a workflow when thepush event occurs.

on:push

Running your workflow only when a push to specific branches occurs

You can use thebranches orbranches-ignore filter to configure your workflow to only run when specific branches are pushed. For more information, seeWorkflow syntax for GitHub Actions.

For example, this workflow will run when someone pushes tomain or to a branch that starts withreleases/.

on:push:branches:-'main'-'releases/**'

on:push:branches:-'releases/**'paths:-'**.js'

Running your workflow only when a push of specific tags occurs

You can use thetags ortags-ignore filter to configure your workflow to only run when specific tags are pushed. For more information, seeWorkflow syntax for GitHub Actions.

For example, this workflow will run when someone pushes a tag that starts withv1..

on:push:tags:-v1.**

Running your workflow only when a push affects specific files

You can use thepaths orpaths-ignore filter to configure your workflow to run when a push to specific files occurs. For more information, seeWorkflow syntax for GitHub Actions.

For example, this workflow will run when someone pushes a change to a JavaScript file (.js):

on:push:paths:-'**.js'

registry_package

jobs:job_name:if:$true

Runs your workflow when activity related to GitHub Packages occurs in your repository. For more information, seeGitHub Packages Documentation.

For example, you can run a workflow when a new package version has beenpublished.

on:registry_package:types: [published]

release

Runs your workflow when release activity in your repository occurs. For information about the release APIs, seeObjects in the GraphQL API documentation orREST API endpoints for releases and release assets in the REST API documentation.

For example, you can run a workflow when a release has beenpublished.

on:release:types: [published]

repository_dispatch

You can use the GitHub API to trigger a webhook event calledrepository_dispatch when you want to trigger a workflow for activity that happens outside of GitHub. For more information, seeREST API endpoints for repositories.

When you make a request to create arepository_dispatch event, you must specify anevent_type to describe the activity type. By default, allrepository_dispatch activity types trigger a workflow to run. You can use thetypes keyword to limit your workflow to run when a specificevent_type value is sent in therepository_dispatch webhook payload.

on:repository_dispatch:types: [test_result]

Any data that you send through theclient_payload parameter will be available in thegithub.event context in your workflow. For example, if you send this request body when you create a repository dispatch event:

{"event_type":"test_result","client_payload":{"passed":false,"message":"Error: timeout"}}

then you can access the payload in a workflow like this:

on:repository_dispatch:types: [test_result]jobs:run_if_failure:if:${{!github.event.client_payload.passed}}runs-on:ubuntu-lateststeps:-env:MESSAGE:${{github.event.client_payload.message}}run:echo$MESSAGE

schedule

Theschedule event allows you to trigger a workflow at a scheduled time.

You can schedule a workflow to run at specific UTC times usingPOSIX cron syntax. Scheduled workflows run on the latest commit on the default or base branch. The shortest interval you can run scheduled workflows is once every 5 minutes.

This example triggers the workflow every day at 5:30 and 17:30 UTC:

on:schedule:# * is a special character in YAML so you have to quote this string-cron:'30 5,17 * * *'

A single workflow can be triggered by multipleschedule events. You can access the schedule event that triggered the workflow through thegithub.event.schedule context. This example triggers the workflow to run at 5:30 UTC every Monday-Thursday, but skips theNot on Monday or Wednesday step on Monday and Wednesday.

on:schedule:-cron:'30 5 * * 1,3'-cron:'30 5 * * 2,4'jobs:test_schedule:runs-on:ubuntu-lateststeps:-name:NotonMondayorWednesdayif:github.event.schedule!='30 5 * * 1,3'run:echo"This step will be skipped on Monday and Wednesday"-name:Everytimerun:echo"This step will always run"

Cron syntax has five fields separated by a space, and each field represents a unit of time.

┌───────────── minute (0 - 59)│ ┌───────────── hour (0 - 23)│ │ ┌───────────── day of the month (1 - 31)│ │ │ ┌───────────── month (1 - 12 or JAN-DEC)│ │ │ │ ┌───────────── day of the week (0 - 6 or SUN-SAT)│ │ │ │ ││ │ │ │ ││ │ │ │ │* * * * *

You can use these operators in any of the five fields:

You can usecrontab guru to help generate your cron syntax and confirm what time it will run. To help you get started, there is also a list ofcrontab guru examples.

Notifications for scheduled workflows are sent to the user who last modified the cron syntax in the workflow file. For more information, seeNotifications for workflow runs.

status

Runs your workflow when the status of a Git commit changes. For example, commits can be marked aserror,failure,pending, orsuccess. If you want to provide more details about the status change, you may want to use thecheck_run event. For information about the commit status APIs, seeObjects in the GraphQL API documentation orREST API endpoints for commits.

For example, you can run a workflow when thestatus event occurs.

on:status

If you want to run a job in your workflow based on the new commit state, you can use thegithub.event.state context. For example, the following workflow triggers when a commit status changes, but theif_error_or_failure job only runs if the new commit state iserror orfailure.

on:statusjobs:if_error_or_failure:runs-on:ubuntu-latestif:>-      github.event.state == 'error' ||      github.event.state == 'failure'steps:-env:DESCRIPTION:${{github.event.description}}run:|          echo The status is error or failed: $DESCRIPTION

watch

Runs your workflow when the workflow's repository is starred. For information about the pull request APIs, seeMutations in the GraphQL API documentation orREST API endpoints for starring.

For example, you can run a workflow when someone stars a repository, which is thestarted activity type for a watch event.

on:watch:types: [started]

workflow_call

workflow_call is used to indicate that a workflow can be called by another workflow. When a workflow is triggered with theworkflow_call event, the event payload in the called workflow is the same event payload from the calling workflow. For more information see,Reuse workflows.

The example below only runs the workflow when it's called from another workflow:

on:workflow_call

workflow_dispatch

To enable a workflow to be triggered manually, you need to configure theworkflow_dispatch event. You can manually trigger a workflow run using the GitHub API, GitHub CLI, or the GitHub UI. For more information, seeManually running a workflow.

on:workflow_dispatch

Providing inputs

You can configure custom-defined input properties, default input values, and required inputs for the event directly in your workflow. When you trigger the event, you can provide theref and anyinputs. When the workflow runs, you can access the input values in theinputs context. For more information, seeContexts reference.

This example defines inputs calledlogLevel,tags, andenvironment. You pass values for these inputs to the workflow when you run it. This workflow then prints the values to the log, using theinputs.logLevel,inputs.tags, andinputs.environment context properties.

on:workflow_dispatch:inputs:logLevel:description:'Log level'required:truedefault:'warning'type:choiceoptions:-info-warning-debugtags:description:'Test scenario tags'required:falsetype:booleanenvironment:description:'Environment to run tests against'type:environmentrequired:truejobs:log-the-inputs:runs-on:ubuntu-lateststeps:-run:|          echo "Log level: $LEVEL"          echo "Tags: $TAGS"          echo "Environment: $ENVIRONMENT"env:LEVEL:${{inputs.logLevel}}TAGS:${{inputs.tags}}ENVIRONMENT:${{inputs.environment}}

If you run this workflow from a browser you must enter values for the required inputs manually before the workflow will run.

You can also pass inputs when you run a workflow from a script, or by using GitHub CLI. For example:

gh workflow run run-tests.yml -f logLevel=warning -f tags=false -f environment=staging

For more information, see the GitHub CLI information inManually running a workflow.

workflow_run

This event occurs when a workflow run is requested or completed. It allows you to execute a workflow based on execution or completion of another workflow. The workflow started by theworkflow_run event is able to access secrets and write tokens, even if the previous workflow was not. This is useful in cases where the previous workflow is intentionally not privileged, but you need to take a privileged action in a later workflow.

In this example, a workflow is configured to run after the separate "Run Tests" workflow completes.

on:workflow_run:workflows: [RunTests]types:-completed

If you specify multipleworkflows for theworkflow_run event, only one of the workflows needs to run. For example, a workflow with the following trigger will run whenever the "Staging" workflow or the "Lab" workflow completes.

on:workflow_run:workflows: [Staging,Lab]types:-completed

Running a workflow based on the conclusion of another workflow

A workflow run is triggered regardless of the conclusion of the previous workflow. If you want to run a job or step based on the result of the triggering workflow, you can use a conditional with thegithub.event.workflow_run.conclusion property. For example, this workflow will run whenever a workflow named "Build" completes, but theon-success job will only run if the "Build" workflow succeeded, and theon-failure job will only run if the "Build" workflow failed:

on:workflow_run:workflows: [Build]types: [completed]jobs:on-success:runs-on:ubuntu-latestif:${{github.event.workflow_run.conclusion=='success'}}steps:-run:echo'The triggering workflow passed'on-failure:runs-on:ubuntu-latestif:${{github.event.workflow_run.conclusion=='failure'}}steps:-run:echo'The triggering workflow failed'

Limiting your workflow to run based on branches

You can use thebranches orbranches-ignore filter to specify what branches the triggering workflow must run on in order to trigger your workflow. For more information, seeWorkflow syntax for GitHub Actions. For example, a workflow with the following trigger will only run when the workflow namedBuild runs on a branch namedcanary.

on:workflow_run:workflows: [Build]types: [requested]branches: [canary]

Using data from the triggering workflow

You can access theworkflow_run event payload that corresponds to the workflow that triggered your workflow. For example, if your triggering workflow generates artifacts, a workflow triggered with theworkflow_run event can access these artifacts.

The following workflow uploads data as an artifact. (In this simplified example, the data is the pull request number.)

name:Uploaddataon:pull_request:jobs:upload:runs-on:ubuntu-lateststeps:-name:SavePRnumberenv:PR_NUMBER:${{github.event.number}}run:|          mkdir -p ./pr          echo $PR_NUMBER > ./pr/pr_number-uses:actions/upload-artifact@v4with:name:pr_numberpath:pr/

When a run of the above workflow completes, it triggers a run of the following workflow. The following workflow uses thegithub.event.workflow_run context and the GitHub REST API to download the artifact that was uploaded by the above workflow, unzips the downloaded artifact, and comments on the pull request whose number was uploaded as an artifact.

name:Usethedataon:workflow_run:workflows: [Uploaddata]types:-completedjobs:download:runs-on:ubuntu-lateststeps:-name:'Download artifact'uses:actions/github-script@v7with:script:|            let allArtifacts = await github.rest.actions.listWorkflowRunArtifacts({               owner: context.repo.owner,               repo: context.repo.repo,               run_id: context.payload.workflow_run.id,            });            let matchArtifact = allArtifacts.data.artifacts.filter((artifact) => {              return artifact.name == "pr_number"            })[0];            let download = await github.rest.actions.downloadArtifact({               owner: context.repo.owner,               repo: context.repo.repo,               artifact_id: matchArtifact.id,               archive_format: 'zip',            });            const fs = require('fs');            const path = require('path');            const temp = '${{ runner.temp }}/artifacts';            if (!fs.existsSync(temp)){              fs.mkdirSync(temp);            }            fs.writeFileSync(path.join(temp, 'pr_number.zip'), Buffer.from(download.data));-name:'Unzip artifact'run:unzippr_number.zip-d"${{ runner.temp }}/artifacts"-name:'Comment on PR'uses:actions/github-script@v7with:github-token:${{secrets.GITHUB_TOKEN}}script:|            const fs = require('fs');            const path = require('path');            const temp = '${{ runner.temp }}/artifacts';            const issue_number = Number(fs.readFileSync(path.join(temp, 'pr_number')));            await github.rest.issues.createComment({              owner: context.repo.owner,              repo: context.repo.repo,              issue_number: issue_number,              body: 'Thank you for the PR!'            });