diff --git a/content/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect.md b/content/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect.md index 69c03b61a4..8a4b945e37 100644 --- a/content/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect.md +++ b/content/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect.md @@ -161,7 +161,7 @@ You can configure a subject that filters for a specific [environment](/actions/d #### Filtering for `pull_request` events -You can configure a subject that filters for the [`pull_request`](/actions/reference/workflow-syntax-for-github-actions#onpushpull_requestbranchestags) event. In this example, the workflow run must have been triggered by a `pull_request` event in a repository named `octo-repo` that is owned by the `octo-org` organization: +You can configure a subject that filters for the [`pull_request`](/actions/learn-github-actions/events-that-trigger-workflows#pull_request) event. In this example, the workflow run must have been triggered by a `pull_request` event in a repository named `octo-repo` that is owned by the `octo-org` organization: | | | diff --git a/content/actions/learn-github-actions/events-that-trigger-workflows.md b/content/actions/learn-github-actions/events-that-trigger-workflows.md index 56e92056f6..b9c3078f49 100644 --- a/content/actions/learn-github-actions/events-that-trigger-workflows.md +++ b/content/actions/learn-github-actions/events-that-trigger-workflows.md @@ -18,33 +18,1245 @@ shortTitle: Events that trigger workflows {% data reusables.actions.enterprise-beta %} {% data reusables.actions.enterprise-github-hosted-runners %} -## Configuring workflow events +## About workflow triggers -You can configure workflows to run for one or more events using the `on` workflow syntax. For more information, see "[Workflow syntax for {% data variables.product.prodname_actions %}](/articles/workflow-syntax-for-github-actions#on)." +Workflow triggers are events that cause a workflow to run. These events can be: -{% data reusables.github-actions.actions-on-examples %} +- Events that occur in your workflow's repository +- Events that occur outside of {% data variables.product.product_name %} and trigger a `repository_dispatch` event on {% data variables.product.product_name %} +- Scheduled times +- Manual -{% note %} +For example, you can configure your workflow to run when a push is made to the default branch of your repository, when a release is created, or when an issue is opened. -**Note:** You cannot trigger new workflow runs using the `GITHUB_TOKEN`. For more information, see "[Triggering new workflows using a personal access token](#triggering-new-workflows-using-a-personal-access-token)." - -{% endnote %} +Workflow triggers are defined with the `on` key. For more information, see "[Workflow syntax for {% data variables.product.prodname_actions %}](/articles/workflow-syntax-for-github-actions#on)." The following steps occur to trigger a workflow run: -1. An event occurs on your repository, and the resulting event has an associated commit SHA and Git ref. -2. The `.github/workflows` directory in your repository is searched for workflow files at the associated commit SHA or Git ref. The workflow files must be present in that commit SHA or Git ref to be considered. +1. An event occurs on your repository. The event has an associated commit SHA and Git ref. +1. {% data variables.product.product_name %} searches the `.github/workflows` directory in your repository for workflow files that are present in the associated commit SHA or Git ref of the event. - For example, if the event occurred on a particular repository branch, then the workflow files must be present in the repository on that branch. -1. The workflow files for that commit SHA and Git ref are inspected, and a new workflow run is triggered for any workflows that have `on:` values that match the triggering event. +1. A workflow run is triggered for any workflows that have `on:` values that match the triggering event. Some events also require the workflow file to be present on the default branch of the repository in order to run. - The workflow runs on your repository's code at the same commit SHA and Git ref that triggered the event. When a workflow runs, {% data variables.product.product_name %} sets the `GITHUB_SHA` (commit SHA) and `GITHUB_REF` (Git ref) environment variables in the runner environment. For more information, see "[Using environment variables](/actions/automating-your-workflow-with-github-actions/using-environment-variables)." + Each workflow run will use the version of the workflow that is present in the associated commit SHA or Git ref of the event. When a workflow runs, {% data variables.product.product_name %} sets the `GITHUB_SHA` (commit SHA) and `GITHUB_REF` (Git ref) environment variables in the runner environment. For more information, see "[Using environment variables](/actions/automating-your-workflow-with-github-actions/using-environment-variables)." -## Scheduled events +### Triggering a workflow from a workflow -The `schedule` event allows you to trigger a workflow at a scheduled time. +{% data reusables.github-actions.actions-do-not-trigger-workflows %} For more information, see "[Authenticating with the GITHUB_TOKEN](/actions/configuring-and-managing-workflows/authenticating-with-the-github_token)." -{% data reusables.actions.schedule-delay %} +If you do want to trigger a workflow from within a workflow run, you can use a personal access token instead of `GITHUB_TOKEN` to trigger events that require a token. You'll need to create a personal access token and store it as a secret. To minimize your {% data variables.product.prodname_actions %} usage costs, ensure that you don't create recursive or unintended workflow runs. For more information about creating a personal access token, see "[Creating a personal access token](/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token)." For more information about storing a personal access token as a secret, see "[Creating and storing encrypted secrets](/actions/configuring-and-managing-workflows/creating-and-storing-encrypted-secrets)." + +For example, the following workflow uses a personal access token (stored as a secret called `MY_TOKEN`) to add a label to an issue via {% data variables.product.prodname_cli %}. Any workflows that run when a label is added will run once this step is performed. + +```yaml +on: + issues: + types: + - opened + +jobs: + label_issue: + runs-on: ubuntu-latest + steps: + - env: + GITHUB_TOKEN: {% raw %}${{ secrets.MY_TOKEN }}{% endraw %} + ISSUE_URL: {% raw %}${{ github.event.issue.html_url }}{% endraw %} + run: | + gh issue edit $ISSUE_URL --add-label "triage" +``` + +Conversely, 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. + +```yaml +on: + issues: + types: + - opened + +jobs: + label_issue: + runs-on: ubuntu-latest + steps: + - env: + GITHUB_TOKEN: {% raw %}${{ secrets.GITHUB_TOKEN }}{% endraw %} + ISSUE_URL: {% raw %}${{ github.event.issue.html_url }}{% endraw %} + run: | + gh issue edit $ISSUE_URL --add-label "triage" +``` + +## Using events to trigger workflows + +Use the `on` key to specify what events trigger your workflow. For more information about events you can use, see "[Available events](#available-events)" below. + +{% data reusables.github-actions.actions-on-examples %} + +## Using event information + +Information 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. + +### Viewing all properties of an event + +Reference the webhook event documentation for common properties and example payloads. For more information, see "[Webhook events and payloads](/developers/webhooks-and-events/webhooks/webhook-events-and-payloads)." + +You can also print the entire `github.event` context to see what properties are available for the event that triggered your workflow: + +```yaml +jobs: + print_context: + runs-on: ubuntu-latest + steps: + - env: + EVENT_CONTEXT: {% raw %}${{ toJSON(github.event) }}{% endraw %} + run: | + echo $EVENT_CONTEXT +``` + +### Accessing and using event properties + +You 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 {% data variables.product.prodname_cli %} to label and comment on the pull request (`github.event.pull_request.number`). + +```yaml +on: + pull_request: + types: + - opened + paths: + - '.github/workflows/**' + - '.github/CODEOWNERS' + - 'package*.json' + +jobs: + triage: + if: >- + github.event.pull_request.user.login != 'octobot' && + github.event.pull_request.user.login != 'dependabot[bot]' + runs-on: ubuntu-latest + steps: + - name: "Comment about changes we can't accept" + env: + GITHUB_TOKEN: {% raw %}${{ secrets.GITHUB_TOKEN }}{% endraw %} + PR: {% raw %}${{ github.event.pull_request.html_url }}{% endraw %} + run: | + gh pr edit $PR --add-label 'invalid' + 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.' +``` + +For more information about contexts, see "[Contexts](/actions/learn-github-actions/contexts)." For more information about event payloads, see "[Webhook events and payloads](/developers/webhooks-and-events/webhooks/webhook-events-and-payloads)." + +## Further controlling how your workflow will run + +If you want more granular control than events, event activity types, or event filters provide, you can use conditionals{% ifversion fpt or ghae or ghes > 3.1 or ghec %} and environments{% endif %} to control whether individual jobs or steps in your workflow will run. + +### Using conditionals + +You can use conditionals to further control whether jobs or steps in your workflow will run. For 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`. + +```yaml +on: + issues: + types: + - labeled + +jobs: + run_if_label_matches: + if: github.event.label.name == 'bug' + runs-on: ubuntu-latest + steps: + - run: echo 'The label was bug' +``` + +For more information, see "[Expressions](/actions/learn-github-actions/expressions)." + +{% ifversion fpt or ghae or ghes > 3.1 or ghec %} +### Using environments to manually trigger workflow jobs + +If 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 "[Using environments for deployment](/actions/deployment/targeting-different-environments/using-environments-for-deployment)." 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. + +For 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`). + +```yaml +on: + push: + branches: + - main + +jobs: + build: + runs-on: ubuntu-latest + steps: + - name: build + echo 'building' + + publish: + needs: [build] + runs-on: ubuntu-latest + environment: production + steps: + - name: publish + echo 'publishing' +``` + +{% note %} + +{% data reusables.gated-features.environments %} + +{% endnote %} +{% endif %} + +## Available events + +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, see "[Webhook events and payloads](/developers/webhooks-and-events/webhook-events-and-payloads)." Note that not all webhook events trigger workflows. + +{% ifversion fpt or ghec or ghes > 3.3 or ghae-issue-4968 %} +### `branch_protection_rule` + +| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` | +| --------------------- | -------------- | ------------ | -------------| +| [`branch_protection_rule`](/developers/webhooks-and-events/webhooks/webhook-events-and-payloads#branch_protection_rule) | - `created`
- `edited`
- `deleted` | Last commit on default branch | Default branch | + +{% note %} + +**Note**: {% data reusables.developer-site.multiple_activity_types %} For information about each activity type, see "[Webhook events and payloads](/developers/webhooks-and-events/webhooks/webhook-events-and-payloads#branch_protection_rule)." {% data reusables.developer-site.limit_workflow_to_activity_types %} + +{% endnote %} + +{% data reusables.github-actions.branch-requirement %} + +Runs your workflow when branch protection rules in the workflow repository are changed. For more information about branch protection rules, see "[About protected branches](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches)." For information about the branch protection rule APIs, see "[BranchProtectionRule](/graphql/reference/objects#branchprotectionrule)" in the GraphQL API documentation or "[Branches](/rest/reference/branches)" in the REST API documentation. + + +For example, you can run a workflow when a branch protection rule has been `created` or `deleted`: + +```yaml +on: + branch_protection_rule: + types: [created, deleted] +``` + +{% endif %} + +### `check_run` + +| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` | +| --------------------- | -------------- | ------------ | -------------| +| [`check_run`](/developers/webhooks-and-events/webhooks/webhook-events-and-payloads/#check_run) | - `created`
- `rerequested`
- `completed`
-`requested_action` | Last commit on default branch | Default branch | + +{% note %} + +**Note**: {% data reusables.developer-site.multiple_activity_types %} For information about each activity type, see "[Webhook events and payloads](/developers/webhooks-and-events/webhooks/webhook-events-and-payloads#check_run)." {% data reusables.developer-site.limit_workflow_to_activity_types %} + +{% endnote %} + +{% data reusables.github-actions.branch-requirement %} + +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, see "[Getting started with the Checks API](/rest/guides/getting-started-with-the-checks-api)." For information about the check run APIs, see "[CheckRun](/graphql/reference/objects#checkrun)" in the GraphQL API documentation or "[Checks](/rest/reference/checks#runs)" in the REST API documentation. + +For example, you can run a workflow when a check run has been `rerequested` or `completed`. + +```yaml +on: + check_run: + types: [rerequested, completed] +``` + +### `check_suite` + +| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` | +| --------------------- | -------------- | ------------ | -------------| +| [`check_suite`](/developers/webhooks-and-events/webhooks/webhook-events-and-payloads/#check_suite) | - `completed` | Last commit on default branch | Default branch | + +{% note %} + +**Note**: {% data reusables.developer-site.multiple_activity_types %} For information about each activity type, see "[Webhook events and payloads](/developers/webhooks-and-events/webhooks/webhook-events-and-payloads#check_suite)." Although only the `started` activity type is supported, specifying the activity type will keep your workflow specific if more activity types are added in the future. {% data reusables.developer-site.limit_workflow_to_activity_types %} + +{% endnote %} + +{% data reusables.github-actions.branch-requirement %} + +{% note %} + +**Note:** To prevent recursive workflows, this event does not trigger workflows if the check suite was created by {% data variables.product.prodname_actions %}. + +{% endnote %} + +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, see "[Getting started with the Checks API](/rest/guides/getting-started-with-the-checks-api)." For information about the check suite APIs, see "[CheckSuite](/graphql/reference/objects#checksuite)" in the GraphQL API documentation or "[Checks](/rest/reference/checks#suites)" in the REST API documentation. + +For example, you can run a workflow when a check suite has been `completed`. + +```yaml +on: + check_suite: + types: [completed] +``` + +### `create` + +| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` | +| --------------------- | -------------- | ------------ | -------------| +| [`create`](/developers/webhooks-and-events/webhooks/webhook-events-and-payloads/#create) | n/a | Last commit on the created branch or tag | Branch or tag created | + +{% note %} + +**Note**: An event will not be created when you create more than three tags at once. + +{% endnote %} + +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, see "[createRef](/graphql/reference/mutations#createref)" in the GraphQL API documentation or "[Create a reference](/rest/reference/git#create-a-reference)" in the REST API documentation. + +For example, you can run a workflow when the `create` event occurs. + +```yaml +on: + create +``` + +### `delete` + +| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` | +| --------------------- | -------------- | ------------ | -------------| +| [`delete`](/developers/webhooks-and-events/webhooks/webhook-events-and-payloads/#delete) | n/a | Last commit on default branch | Default branch | + +{% data reusables.github-actions.branch-requirement %} + +{% note %} + +**Note**: An event will not be created when you delete more than three tags at once. + +{% endnote %} + +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, see "[deleteRef](/graphql/reference/mutations#deleteref)" in the GraphQL API documentation or "[Delete a reference](/rest/reference/git#delete-a-reference)" in the REST API documentation. + +For example, you can run a workflow when the `delete` event occurs. + +```yaml +on: + delete +``` + +### `deployment` + +| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` | +| --------------------- | -------------- | ------------ | -------------| +| [`deployment`](/developers/webhooks-and-events/webhooks/webhook-events-and-payloads/#deployment) | n/a | Commit to be deployed | Branch or tag to be deployed (empty if created with a commit SHA)| + +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, see "[createDeployment](/graphql/reference/mutations#createdeployment)" in the GraphQL API documentation or "[Deployments](/rest/reference/repos#deployments)" in the REST API documentation. + +For example, you can run a workflow when the `deployment` event occurs. + +```yaml +on: + deployment +``` + +### `deployment_status` + +| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` | +| --------------------- | -------------- | ------------ | -------------| +| [`deployment_status`](/developers/webhooks-and-events/webhooks/webhook-events-and-payloads/#deployment_status) | n/a | Commit to be deployed | Branch or tag to be deployed (empty if commit)| + +{% note %} + +**Note:** When a deployment status's state is set to `inactive`, a workflow run will not be triggered. + +{% endnote %} + +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, see "[createDeploymentStatus](/graphql/reference/mutations#createdeploymentstatus)" in the GraphQL API documentation or "[Create a deployment status](/rest/reference/deployments#create-a-deployment-status)" in the REST API documentation. + +For example, you can run a workflow when the `deployment_status` event occurs. + +```yaml +on: + deployment_status +``` + +{% ifversion fpt or ghec %} +### `discussion` + +| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` | +| --------------------- | -------------- | ------------ | -------------| +| [`discussion`](/developers/webhooks-and-events/webhooks/webhook-events-and-payloads/#discussion) | - `created`
- `edited`
- `deleted`
- `transferred`
- `pinned`
- `unpinned`
- `labeled`
- `unlabeled`
- `locked`
- `unlocked`
- `category_changed`
- `answered`
- `unanswered` | Last commit on default branch | Default branch | + +{% note %} + +**Note**: {% data reusables.developer-site.multiple_activity_types %} For information about each activity type, see "[Webhook events and payloads](/developers/webhooks-and-events/webhooks/webhook-events-and-payloads#discussion)." {% data reusables.developer-site.limit_workflow_to_activity_types %} + +{% endnote %} + +{% data reusables.github-actions.branch-requirement %} + +{% data reusables.webhooks.discussions-webhooks-beta %} + +Runs your workflow when a discussion in the workflow's repository is created or modified. For activity related to comments on a discussion, use the [`discussion_comment`](#discussion_comment) event. For more information about discussions, see "[About discussions](/discussions/collaborating-with-your-community-using-discussions/about-discussions)." For information about the GraphQL API, see "[Discussion](/graphql/reference/objects#discussion)." + +For example, you can run a workflow when a discussion has been `created`, `edited`, or `answered`. + +```yaml +on: + discussion: + types: [created, edited, answered] +``` + +### `discussion_comment` + +| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` | +| --------------------- | -------------- | ------------ | -------------| +| [`discussion_comment`](/developers/webhooks-and-events/webhook-events-and-payloads#discussion_comment) | - `created`
- `edited`
- `deleted`
| Last commit on default branch | Default branch | + +{% note %} + +**Note**: {% data reusables.developer-site.multiple_activity_types %} For information about each activity type, see "[Webhook events and payloads](/developers/webhooks-and-events/webhooks/webhook-events-and-payloads#discussion_comment)." {% data reusables.developer-site.limit_workflow_to_activity_types %} + +{% endnote %} + +{% data reusables.github-actions.branch-requirement %} + +{% data reusables.webhooks.discussions-webhooks-beta %} + +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 the [`discussion`](#discussion) event. For more information about discussions, see "[About discussions](/discussions/collaborating-with-your-community-using-discussions/about-discussions)." For information about the GraphQL API, see "[Discussion](/graphql/reference/objects#discussion)." + +For example, you can run a workflow when a discussion comment has been `created` or `deleted`. + +```yaml +on: + discussion_comment: + types: [created, deleted] +``` + +{% endif %} + +### `fork` + +| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` | +| --------------------- | -------------- | ------------ | -------------| +| [`fork`](/developers/webhooks-and-events/webhooks/webhook-events-and-payloads/#fork) | n/a | Last commit on default branch | Default branch | + +{% data reusables.github-actions.branch-requirement %} + +Runs your workflow when someone forks a repository. For information about the REST API, see "[Create a fork](/rest/reference/repos#create-a-fork)." + +For example, you can run a workflow when the `fork` event occurs. + +```yaml +on: + fork +``` + +### `gollum` + +| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` | +| --------------------- | -------------- | ------------ | -------------| +| [`gollum`](/developers/webhooks-and-events/webhooks/webhook-events-and-payloads/#gollum) | n/a | Last commit on default branch | Default branch | + +{% data reusables.github-actions.branch-requirement %} + +Runs your workflow when someone creates or updates a Wiki page. For more information, see "[About wikis](/communities/documenting-your-project-with-wikis/about-wikis)." + +For example, you can run a workflow when the `gollum` event occurs. + +```yaml +on: + gollum +``` + +### `issue_comment` + +| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` | +| --------------------- | -------------- | ------------ | -------------| +| [`issue_comment`](/developers/webhooks-and-events/webhook-events-and-payloads#issue_comment) | - `created`
- `edited`
- `deleted`
| Last commit on default branch | Default branch | + +{% note %} + +**Note**: {% data reusables.developer-site.multiple_activity_types %} For information about each activity type, see "[Webhook events and payloads](/developers/webhooks-and-events/webhooks/webhook-events-and-payloads#issue_comment)." {% data reusables.developer-site.limit_workflow_to_activity_types %} + +{% endnote %} + +{% data reusables.github-actions.branch-requirement %} + +Runs your workflow when an issue or pull request comment is created, edited, or deleted. For information about the issue comment APIs, see "[IssueComment](/graphql/reference/objects#issuecomment)" in the GraphQL API documentation or "[Issue comments](/developers/webhooks-and-events/webhook-events-and-payloads#issue_comment)" in the REST API documentation. + +For example, you can run a workflow when an issue or pull request comment has been `created` or `deleted`. + +```yaml +on: + issue_comment: + types: [created, deleted] +``` + +#### `issue_comment` on issues only or pull requests only + +The `issue_comment` event occurs for comments on both issues and pull requests. You can use the `github.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 the `pr_commented` job only if the `issue_comment` event originated from a pull request. It will run the `issue_commented` job only if the `issue_comment` event originated from an issue. + +```yaml +on: issue_comment + +jobs: + pr_commented: + # This job only runs for pull request comments + name: PR comment + if: {% raw %}${{ github.event.issue.pull_request }}{% endraw %} + runs-on: ubuntu-latest + steps: + - run: | + echo A comment on PR $NUMBER + env: + NUMBER: {% raw %}${{ github.event.issue.number }}{% endraw %} + + issue_commented: + # This job only runs for issue comments + name: Issue comment + if: {% raw %}${{ !github.event.issue.pull_request }}{% endraw %} + runs-on: ubuntu-latest + steps: + - run: | + echo A comment on issue $NUMBER + env: + NUMBER: {% raw %}${{ github.event.issue.number }}{% endraw %} +``` + +### `issues` + +| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` | +| --------------------- | -------------- | ------------ | -------------| +| [`issues`](/developers/webhooks-and-events/webhooks/webhook-events-and-payloads/#issues) | - `opened`
- `edited`
- `deleted`
- `transferred`
- `pinned`
- `unpinned`
- `closed`
- `reopened`
- `assigned`
- `unassigned`
- `labeled`
- `unlabeled`
- `locked`
- `unlocked`
- `milestoned`
- `demilestoned` | Last commit on default branch | Default branch | + +{% note %} + +**Note**: {% data reusables.developer-site.multiple_activity_types %} For information about each activity type, see "[Webhook events and payloads](/developers/webhooks-and-events/webhooks/webhook-events-and-payloads#issues)." {% data reusables.developer-site.limit_workflow_to_activity_types %} + +{% endnote %} + +{% data reusables.github-actions.branch-requirement %} + +Runs your workflow when an issue in the workflow's repository is created or modified. For activity related to comments in an issue, use the [`issue_comment`](#issue_comment) event. For more information about issues, see "[About issues](/issues/tracking-your-work-with-issues/about-issues)." For information about the issue APIs, see "[Issue](/graphql/reference/objects#issue)" in the GraphQL API documentation or "[Issues](/rest/reference/issues)" in the REST API documentation. + +For example, you can run a workflow when an issue has been `opened`, `edited`, or `milestoned`. + +```yaml +on: + issues: + types: [opened, edited, milestoned] +``` + +### `label` + +| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` | +| --------------------- | -------------- | ------------ | -------------| +| [`label`](/developers/webhooks-and-events/webhooks/webhook-events-and-payloads/#label) | - `created`
- `edited`
- `deleted`
| Last commit on default branch | Default branch | + +{% note %} + +**Note**: {% data reusables.developer-site.multiple_activity_types %} For information about each activity type, see "[Webhook events and payloads](/developers/webhooks-and-events/webhooks/webhook-events-and-payloads#label)." {% data reusables.developer-site.limit_workflow_to_activity_types %} + +{% endnote %} + +{% data reusables.github-actions.branch-requirement %} + +Runs your workflow when a label in your workflow's repository is created or modified. For more information about labels, see "[Managing labels](/issues/using-labels-and-milestones-to-track-work/managing-labels)." For information about the label APIs, see "[Label](/graphql/reference/objects#label)" in the GraphQL API documentation or "[Labels](/rest/reference/issues#labels)" in the REST API documentation. + +If you want to run your workflow when a label is added to or removed from an issue, pull request, or discussion, use the `labeled` or `unlabeled` activity types for the [`issues`](#issues), [`pull_request`](#pull_request), [`pull_request_target`](#pull_request_target), or [`discussion`](#discussion) events instead. + +For example, you can run a workflow when a label has been `created` or `deleted`. + +```yaml +on: + label: + types: [created, deleted] +``` + +### `milestone` + +| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` | +| --------------------- | -------------- | ------------ | -------------| +| [`milestone`](/developers/webhooks-and-events/webhooks/webhook-events-and-payloads/#milestone) | - `created`
- `closed`
- `opened`
- `edited`
- `deleted`
| Last commit on default branch | Default branch | + +{% note %} + +**Note**: {% data reusables.developer-site.multiple_activity_types %} For information about each activity type, see "[Webhook events and payloads](/developers/webhooks-and-events/webhooks/webhook-events-and-payloads#milestone)." {% data reusables.developer-site.limit_workflow_to_activity_types %} + +{% endnote %} + +{% data reusables.github-actions.branch-requirement %} + +Runs your workflow when a milestone in the workflow's repository is created or modified. For more information about milestones, see "[About milestones](/issues/using-labels-and-milestones-to-track-work/about-milestones)." For information about the milestone APIs, see "[Milestone](/graphql/reference/objects#milestone)" in the GraphQL API documentation or "[Milestones](/rest/reference/issues#milestones)" in the REST API documentation. + +If you want to run your workflow when an issue is added to or removed from a milestone, use the `milestoned` or `demilestoned` activity types for the [`issues`](#issues) event instead. + +For example, you can run a workflow when a milestone has been `opened` or `deleted`. + +```yaml +on: + milestone: + types: [opened, deleted] +``` + +### `page_build` + +| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` | +| --------------------- | -------------- | ------------ | -------------| +| [`page_build`](/developers/webhooks-and-events/webhooks/webhook-events-and-payloads/#page_build) | n/a | Last commit on default branch | n/a | + +{% data reusables.github-actions.branch-requirement %} + +Runs your workflow when someone pushes to a branch that is the publishing source for {% data variables.product.prodname_pages %}, if {% data variables.product.prodname_pages %} is enabled for the repository. For more information about {% data variables.product.prodname_pages %} publishing sources, see "[Configuring a publishing source for your GitHub Pages site](/pages/getting-started-with-github-pages/configuring-a-publishing-source-for-your-github-pages-site#choosing-a-publishing-source)." For information about the REST API, see "[Pages](/rest/reference/repos#pages)." + +For example, you can run a workflow when the `page_build` event occurs. + +```yaml +on: + page_build +``` + +### `project` + +| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` | +| --------------------- | -------------- | ------------ | -------------| +| [`project`](/developers/webhooks-and-events/webhooks/webhook-events-and-payloads/#project) | - `created`
- `closed`
- `reopened`
- `edited`
- `deleted`
| Last commit on default branch | Default branch | + +{% note %} + +**Note**: {% data reusables.developer-site.multiple_activity_types %} The `edited` activity type refers to when a project board, not a column or card on the project board, is edited. For information about each activity type, see "[Webhook events and payloads](/developers/webhooks-and-events/webhooks/webhook-events-and-payloads#project)." {% data reusables.developer-site.limit_workflow_to_activity_types %} + +{% endnote %} + +{% data reusables.github-actions.branch-requirement %} + +{% note %} + +**Note**: This event only occurs for projects owned by the workflow's repository, not for organization-owned or user-owned projects or for projects owned by another repository. + +{% endnote %} + +{% ifversion fpt or ghec %} +{% note %} + +**Note**: This event does not occur for projects (beta). For more information, see "[About projects (beta)](/issues/trying-out-the-new-projects-experience/about-projects)." + +{% endnote %} +{% endif %} + +Runs your workflow when a project board is created or modified. For activity related to cards or columns in a project board, use the [`project_card`](#project_card) or [`project_column`](#project_column) events instead. For more information about project boards, see "[About project boards](/issues/organizing-your-work-with-project-boards/managing-project-boards/about-project-boards)." For information about the project board APIs, see "[Project](/graphql/reference/objects#project)" in the GraphQL API documentation or "[Projects](/rest/reference/projects)" in the REST API documentation. + +For example, you can run a workflow when a project has been `created` or `deleted`. + +```yaml +on: + project: + types: [created, deleted] +``` + +### `project_card` + +| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` | +| --------------------- | -------------- | ------------ | -------------| +| [`project_card`](/developers/webhooks-and-events/webhooks/webhook-events-and-payloads/#project_card) | - `created`
- `moved`
- `converted` to an issue
- `edited`
- `deleted` | Last commit on default branch | Default branch | + +{% note %} + +**Note**: {% data reusables.developer-site.multiple_activity_types %} For information about each activity type, see "[Webhook events and payloads](/developers/webhooks-and-events/webhooks/webhook-events-and-payloads#project_card)." {% data reusables.developer-site.limit_workflow_to_activity_types %} + +{% endnote %} + +{% data reusables.github-actions.branch-requirement %} + +{% note %} + +**Note**: This event only occurs for projects owned by the workflow's repository, not for organization-owned or user-owned projects or for projects owned by another repository. + +{% endnote %} + +{% ifversion fpt or ghec %} +{% note %} + +**Note**: This event does not occur for projects (beta). For more information, see "[About projects (beta)](/issues/trying-out-the-new-projects-experience/about-projects)." + +{% endnote %} +{% endif %} + +Runs your workflow when a card on a project board is created or modified. For activity related to project boards or columns in a project board, use the [`project`](#project) or [`project_column`](#project_column) event instead. For more information about project boards, see "[About project boards](/issues/organizing-your-work-with-project-boards/managing-project-boards/about-project-boards)." For information about the project card APIs, see "[ProjectCard](/graphql/reference/objects#projectcard)" in the GraphQL API documentation or "[Project cards](/rest/reference/projects#cards)" in the REST API documentation. + +For example, you can run a workflow when a project card has been `created` or `deleted`. + +```yaml +on: + project_card: + types: [created, deleted] +``` + +### `project_column` + +| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` | +| --------------------- | -------------- | ------------ | -------------| +| [`project_column`](/developers/webhooks-and-events/webhooks/webhook-events-and-payloads/#project_column) | - `created`
- `updated`
- `moved`
- `deleted` | Last commit on default branch | Default branch | + +{% note %} + +**Note**: {% data reusables.developer-site.multiple_activity_types %} For information about each activity type, see "[Webhook events and payloads](/developers/webhooks-and-events/webhooks/webhook-events-and-payloads#project_column)." {% data reusables.developer-site.limit_workflow_to_activity_types %} + +{% endnote %} + +{% data reusables.github-actions.branch-requirement %} + +{% note %} + +**Note**: This event only occurs for projects owned by the workflow's repository, not for organization-owned or user-owned projects or for projects owned by another repository. + +{% endnote %} + +{% ifversion fpt or ghec %} +{% note %} + +**Note**: This event does not occur for projects (beta). For more information, see "[About projects (beta)](/issues/trying-out-the-new-projects-experience/about-projects)." + +{% endnote %} +{% endif %} + +Runs your workflow when a column on a project board is created or modified. For activity related to project boards or cards in a project board, use the [`project`](#project) or [`project_card`](#project_card) event instead. For more information about project boards, see "[About project boards](/issues/organizing-your-work-with-project-boards/managing-project-boards/about-project-boards)." For information about the project column APIs, see "[Project Column](/graphql/reference/objects#projectcolumn)" in the GraphQL API documentation or "[Project columns](/rest/reference/projects#columns)" in the REST API documentation. + +For example, you can run a workflow when a project column has been `created` or `deleted`. + +```yaml +on: + project_column: + types: [created, deleted] +``` + +### `public` + +| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` | +| --------------------- | -------------- | ------------ | -------------| +| [`public`](/developers/webhooks-and-events/webhooks/webhook-events-and-payloads/#public) | n/a | Last commit on default branch | Default branch | + +{% data reusables.github-actions.branch-requirement %} + +Runs your workflow when your workflow's repository changes from private to public. For information about the REST API, see "[Edit repositories](/rest/reference/repos#edit)." + +For example, you can run a workflow when the `public` event occurs. + +```yaml +on: + public +``` + +### `pull_request` + +| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` | +| --------------------- | -------------- | ------------ | -------------| +| [`pull_request`](/developers/webhooks-and-events/webhooks/webhook-events-and-payloads/#pull_request) | - `assigned`
- `unassigned`
- `labeled`
- `unlabeled`
- `opened`
- `edited`
- `closed`
- `reopened`
- `synchronize`
- `converted_to_draft`
- `ready_for_review`
- `locked`
- `unlocked`
- `review_requested`
- `review_request_removed`{% ifversion fpt or ghes > 3.0 or ghae or ghec %}
- `auto_merge_enabled`
- `auto_merge_disabled`{% endif %} | Last merge commit on the `GITHUB_REF` branch | PR merge branch `refs/pull/:prNumber/merge` | + +{% note %} + +**Note**: {% data reusables.developer-site.multiple_activity_types %} For information about each activity type, see "[Webhook events and payloads](/developers/webhooks-and-events/webhooks/webhook-events-and-payloads#pull_request)." By default, a workflow only runs when a `pull_request` event's activity type is `opened`, `synchronize`, or `reopened`. You can specify different activity types using the `types` keyword. For more information, see "[Workflow syntax for {% data variables.product.prodname_actions %}](/articles/workflow-syntax-for-github-actions#onevent_nametypes)." + +{% endnote %} + +{% note %} + +**Note:** By default, only the `opened`, `synchronize`, and `reopened` activity types trigger workflows that run on the `pull_request` event. To trigger workflows by different activity types, use the `types` keyword. + +{% endnote %} + +{% note %} + +**Note:** Workflows will not run on `pull_request` activity if the pull request has a merge conflict. The merge conflict must be resolved first. + +Conversely, workflows with the `pull_request_target` event will run even if the pull request has a merge conflict. Before using the `pull_request_target` trigger, you should be aware of the security risks. For more information, see [`pull_request_target`](#pull_request_target). + +{% endnote %} + +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 the [`pull_request_review`](#pull_request_review), [`pull_request_review_comment`](#pull_request_review_comment), or [`issue_comment`](#issue_comment) events instead. For information about the pull request APIs, see "[PullRequest](/graphql/reference/objects#pullrequest)" in the GraphQL API documentation or "[Pull requests](/rest/reference/pulls)" in the REST API documentation. + +Note that `GITHUB_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, use `github.event.pull_request.head.sha` instead. + +For example, you can run a workflow when a pull request has been opened or reopened. + +```yaml +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 the `specific_review_requested` job will only run when a review by `octo-team` is requested. + +```yaml +on: + pull_request: + types: [review_requested] +jobs: + specific_review_requested: + runs-on: ubuntu-latest + if: {% raw %}${{ github.event.requested_team.name == 'octo-team'}}{% endraw %} + steps: + - run: echo 'A review from octo-team was requested' +``` + +#### Running your workflow based on the head or base branch of a pull request + +You can use the `branches` or `branches-ignore` filter to configure your workflow to only run on pull requests that target specific branches. For more information, see "[Workflow syntax for GitHub Actions](/actions/learn-github-actions/workflow-syntax-for-github-actions#onpull_requestpull_request_targetbranchesbranches-ignore)." + +For example, this workflow will run when someone opens a pull request that targets a branch whose name starts with `releases/`: + +```yaml +on: + pull_request: + types: + - opened + branches: + - 'releases/**' +``` + +{% note %} + +**Note:** {% data reusables.github-actions.branch-paths-filter %} For example, the following workflow will only run when a pull request that includes a change to a JavaScript (`.js`) file is opened on a branch whose name starts with `releases/`: + +```yaml +on: + pull_request: + types: + - opened + branches: + - 'releases/**' + paths: + - '**.js' +``` + +{% endnote %} + +To run a job based on the pull request's head branch name (as opposed to the pull request's base branch name), use the `github.head_ref` context in a conditional. For example, this workflow will run whenever a pull request is opened, but the `run_if` job will only execute if the head of the pull request is a branch whose name starts with `releases/`: + +```yaml +on: + pull_request: + types: + - opened +jobs: + run_if: + if: startsWith(github.head_ref, 'releases/') + runs-on: ubuntu-latest + steps: + - run: echo "The head of this PR starts with 'releases/'" +``` + +#### Running your 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, see "[Workflow syntax for GitHub Actions](/actions/learn-github-actions/workflow-syntax-for-github-actions#onpushpull_requestpull_request_targetpathspaths-ignore)." + +For example, this workflow will run when a pull request includes a change to a JavaScript file (`.js`): + +```yaml +on: + pull_request: + paths: + - '**.js' +``` + +{% note %} + +**Note:** {% data reusables.github-actions.branch-paths-filter %} For example, the following workflow will only run when a pull request that includes a change to a JavaScript (`.js`) file is opened on a branch whose name starts with `releases/`: + +```yaml +on: + pull_request: + types: + - opened + branches: + - 'releases/**' + paths: + - '**.js' +``` + +{% endnote %} + +{% data reusables.developer-site.pull_request_forked_repos_link %} + +### `pull_request_comment` (use `issue_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 the [`issue_comment`](#issue_comment) event. For activity related to pull request reviews or pull request review comments, use the [`pull_request_review`](#pull_request_review) or [`pull_request_review_comment`](#pull_request_review_comment) events. + +### `pull_request_review` + +| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` | +| --------------------- | -------------- | ------------ | -------------| +| [`pull_request_review`](/developers/webhooks-and-events/webhooks/webhook-events-and-payloads/#pull_request_review) | - `submitted`
- `edited`
- `dismissed` | Last merge commit on the `GITHUB_REF` branch | PR merge branch `refs/pull/:prNumber/merge` | + +{% note %} + +**Note**: {% data reusables.developer-site.multiple_activity_types %} For information about each activity type, see "[Webhook events and payloads](/developers/webhooks-and-events/webhooks/webhook-events-and-payloads#pull_request_review)." {% data reusables.developer-site.limit_workflow_to_activity_types %} + +{% endnote %} + +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 the [`pull_request_review_comment`](#pull_request_review_comment) or [`issue_comment`](#issue_comment) events instead. For information about the pull request review APIs, see "[PullRequestReview](/graphql/reference/objects#pullrequest)" in the GraphQL API documentation or "[Pull request reviews](/rest/reference/pulls#reviews)" in the REST API documentation. + +For example, you can run a workflow when a pull request review has been `edited` or `dismissed`. + +```yaml +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 the `submitted` type of `pull_request_review` event, then check the review state with the `github.event.review.state` property. For example, this workflow will run whenever a pull request review is submitted, but the `approved` job will only run if the submitted review is an approving review: + +```yaml +on: + pull_request_review: + types: [submitted] + +jobs: + approved: + if: github.event.review.state == 'approved' + runs-on: ubuntu-latest + steps: + - run: echo "This PR was approved" +``` + +{% data reusables.developer-site.pull_request_forked_repos_link %} + +### `pull_request_review_comment` + +| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` | +| --------------------- | -------------- | ------------ | -------------| +| [`pull_request_review_comment`](/developers/webhooks-and-events/webhooks/webhook-events-and-payloads/#pull_request_review_comment) | - `created`
- `edited`
- `deleted`| Last merge commit on the `GITHUB_REF` branch | PR merge branch `refs/pull/:prNumber/merge` | + +{% note %} + +**Note**: {% data reusables.developer-site.multiple_activity_types %} For information about each activity type, see "[Webhook events and payloads](/developers/webhooks-and-events/webhooks/webhook-events-and-payloads#pull_request_review_comment)." {% data reusables.developer-site.limit_workflow_to_activity_types %} + +{% endnote %} + +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 the [`pull_request_review`](#pull_request_review) or [`issue_comment`](#issue_comment) events instead. For information about the pull request review comment APIs, see "[PullRequestReviewComment](/graphql/reference/objects#pullrequestreviewcomment)" in the GraphQL API documentation or "[Review comments](/rest/reference/pulls#comments)" in the REST API documentation. + +For example, you can run a workflow when a pull request review comment has been `created` or `deleted`. + +```yaml +on: + pull_request_review_comment: + types: [created, deleted] +``` + +{% data reusables.developer-site.pull_request_forked_repos_link %} + +### `pull_request_target` + +| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` | +| --------------------- | -------------- | ------------ | -------------| +| [`pull_request`](/developers/webhooks-and-events/webhooks/webhook-events-and-payloads/#pull_request) | - `assigned`
- `unassigned`
- `labeled`
- `unlabeled`
- `opened`
- `edited`
- `closed`
- `reopened`
- `synchronize`
- `converted_to_draft`
- `ready_for_review`
- `locked`
- `unlocked`
- `review_requested`
- `review_request_removed`{% ifversion fpt or ghes > 3.0 or ghae or ghec %}
- `auto_merge_enabled`
- `auto_merge_disabled`{% endif %} | Last commit on the PR base branch | PR base branch | + +{% note %} + +**Note**: {% data reusables.developer-site.multiple_activity_types %} For information about each activity type, see "[Webhook events and payloads](/developers/webhooks-and-events/webhooks/webhook-events-and-payloads#pull_request_target)." By default, a workflow only runs when a `pull_request_target`'s activity type is `opened`, `synchronize`, or `reopened`. To trigger workflows for more activity types, use the `types` keyword. You can specify different activity types using the `types` keyword. For more information, see "[Workflow syntax for {% data variables.product.prodname_actions %}](/articles/workflow-syntax-for-github-actions#onevent_nametypes)." + +{% endnote %} + +{% note %} + +**Note:** By default, only the `opened`, `synchronize`, and `reopened` activity types trigger workflows that run on the `pull_request` event. To trigger workflows by different activity types, use the `types` keyword. + +{% endnote %} + +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 the `pull_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. + +{% warning %} + +**Warning:** For workflows that are triggered by the `pull_request_target` event, the `GITHUB_TOKEN` is granted read/write repository permission unless the `permissions` key is specified and the workflow can access secrets, even when it is triggered from a fork. Although the workflow runs in the context of the base of the pull request, you should make sure that you do not check out, build, or run untrusted code from the pull request with this event. Additionally, any caches share the same scope as the base branch. To help prevent cache poisoning, you should not save the cache if there is a possibility that the cache contents were altered. For more information, see "[Keeping your GitHub Actions and workflows secure: Preventing pwn requests](https://securitylab.github.com/research/github-actions-preventing-pwn-requests)" on the GitHub Security Lab website. + +{% endwarning %} + +For example, you can run a workflow when a pull request has been `assigned`, `opened`, `synchronize`, or `reopened`. + +```yaml +on: + pull_request_target: + types: [assigned, opened, synchronize, reopened] +``` + +#### Running your workflow based on the head or base branch of a pull request + +You can use the `branches` or `branches-ignore` filter to configure your workflow to only run on pull requests that target specific branches. For more information, see "[Workflow syntax for GitHub Actions](/actions/learn-github-actions/workflow-syntax-for-github-actions#onpull_requestpull_request_targetbranchesbranches-ignore)." + +For example, this workflow will run when someone opens a pull request that targets a branch whose name starts with `releases/`: + +```yaml +on: + pull_request_target: + types: + - opened + branches: + - 'releases/**' +``` + +{% note %} + +**Note:** {% data reusables.github-actions.branch-paths-filter %} For example, the following workflow will only run when a pull request that includes a change to a JavaScript (`.js`) file is opened on a branch whose name starts with `releases/`: + +```yaml +on: + pull_request_target: + types: + - opened + branches: + - 'releases/**' + paths: + - '**.js' +``` + +{% endnote %} + +To run a job based on the pull request's head branch name (as opposed to the pull request's base branch name), use the `github.head_ref` context in a conditional. For example, this workflow will run whenever a pull request is opened, but the `run_if` job will only execute if the head of the pull request is a branch whose name starts with `releases/`: + +```yaml +on: + pull_request: + types: + - opened +jobs: + run_if: + if: startsWith(github.head_ref, 'releases/') + runs-on: ubuntu-latest + steps: + - run: echo "The head of this PR starts with 'releases/'" +``` + +#### Running your workflow based on files changed in a pull request + +You can use the `paths` or `paths-ignore` filter to configure your workflow to run when a pull request changes specific files. For more information, see "[Workflow syntax for GitHub Actions](/actions/learn-github-actions/workflow-syntax-for-github-actions#onpushpull_requestpull_request_targetpathspaths-ignore)." + +For example, this workflow will run when a pull request includes a change to a JavaScript file (`.js`): + +```yaml +on: + pull_request_target: + paths: + - '**.js' +``` + +{% note %} + +**Note:** {% data reusables.github-actions.branch-paths-filter %} For example, the following workflow will only run when a pull request that includes a change to a JavaScript (`.js`) file is opened on a branch whose name starts with `releases/`: + +```yaml +on: + pull_request_target: + types: + - opened + branches: + - 'releases/**' + paths: + - '**.js' +``` + +{% endnote %} + +### `push` + +| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` | +| --------------------- | -------------- | ------------ | -------------| +| [`push`](/developers/webhooks-and-events/webhooks/webhook-events-and-payloads/#push) | n/a | Commit pushed, unless deleting a branch (when it's the default branch) | Updated ref | + +{% note %} + +**Note:** The webhook payload available to GitHub Actions does not include the `added`, `removed`, and `modified` attributes in the `commit` object. You can retrieve the full commit object using the API. For information, see "[Commit](/graphql/reference/objects#commit)" in the GraphQL API documentation or "[Get a commit](/rest/reference/commits#get-a-commit)" in the REST API documentation. + +{% endnote %} + +{% note %} + +**Note**: An event will not be created when you push more than three tags at once. + +{% endnote %} + +Runs your workflow when you push a commit or tag. + +For example, you can run a workflow when the `push` event occurs. + +```yaml +on: + push +``` + +#### Running your workflow only when a push to specific branches occurs + +You can use the `branches` or `branches-ignore` filter to configure your workflow to only run when specific branches are pushed. For more information, see "[Workflow syntax for GitHub Actions](/actions/learn-github-actions/workflow-syntax-for-github-actions#onpushbranchestagsbranches-ignoretags-ignore)." + +For example, this workflow will run when someone pushes to `main` or to a branch that starts with `releases/`. + +```yaml +on: + push: + branches: + - 'main' + - 'releases/**' +``` + +{% note %} + +**Note:** {% data reusables.github-actions.branch-paths-filter %} For example, the following workflow will only run when a push that includes a change to a JavaScript (`.js`) file is made to a branch whose name starts with `releases/`: + +```yaml +on: + push: + types: + - opened + branches: + - 'releases/**' + paths: + - '**.js' +``` + +{% endnote %} + +#### Running your workflow only when a push of specific tags occurs + +You can use the `tags` or `tags-ignore` filter to configure your workflow to only run when specific tags or are pushed. For more information, see "[Workflow syntax for GitHub Actions](/actions/learn-github-actions/workflow-syntax-for-github-actions#onpushbranchestagsbranches-ignoretags-ignore)." + +For example, this workflow will run when someone pushes a tag that starts with `v1.`. + +```yaml +on: + push: + tags: + - v1.** +``` + +#### Running your workflow only when a push affects specific files + +You can use the `paths` or `paths-ignore` filter to configure your workflow to run when a push to specific files occurs. For more information, see "[Workflow syntax for GitHub Actions](/actions/learn-github-actions/workflow-syntax-for-github-actions#onpushpull_requestpull_request_targetpathspaths-ignore)." + +For example, this workflow will run when someone pushes a change to a JavaScript file (`.js`): + +```yaml +on: + push: + paths: + - '**.js' +``` + +{% note %} + +**Note:** {% data reusables.github-actions.branch-paths-filter %} For example, the following workflow will only run when a push that includes a change to a JavaScript (`.js`) file is made to a branch whose name starts with `releases/`: + +```yaml +on: + push: + types: + - opened + branches: + - 'releases/**' + paths: + - '**.js' +``` + +{% endnote %} + +### `registry_package` + +| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` | +| --------------------- | -------------- | ------------ | -------------| +| [`registry_package`](/developers/webhooks-and-events/webhooks/webhook-events-and-payloads/#package) | - `published`
- `updated` | Commit of the published package | Branch or tag of the published package | + +{% note %} + +**Note**: {% data reusables.developer-site.multiple_activity_types %} For information about each activity type, see "[Webhook events and payloads](/developers/webhooks-and-events/webhooks/webhook-events-and-payloads#registry_package)." {% data reusables.developer-site.limit_workflow_to_activity_types %} + +{% endnote %} + +{% data reusables.github-actions.branch-requirement %} + +Runs your workflow when activity related to {% data variables.product.prodname_registry %} occurs in your repository. For more information, see "[{% data variables.product.prodname_registry %} Documentation](/packages)." + +For example, you can run a workflow when a package has been `published`. + +```yaml +on: + registry_package: + types: [published] +``` + +### `release` + +| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` | +| --------------------- | -------------- | ------------ | -------------| +| [`release`](/developers/webhooks-and-events/webhooks/webhook-events-and-payloads/#release) | - `published`
- `unpublished`
- `created`
- `edited`
- `deleted`
- `prereleased`
- `released` | Last commit in the tagged release | Tag of release | + +{% note %} + +**Note**: {% data reusables.developer-site.multiple_activity_types %} For information about each activity type, see "[Webhook events and payloads](/developers/webhooks-and-events/webhooks/webhook-events-and-payloads#release)." {% data reusables.developer-site.limit_workflow_to_activity_types %} + +{% endnote %} + +{% note %} + +**Note:** Workflows are not triggered for the `created`, `edited`, or `deleted` activity types for draft releases. When you create your release through the {% data variables.product.product_name %} browser UI, your release may automatically be saved as a draft. + +{% endnote %} + +{% note %} + +**Note:** The `prereleased` type will not trigger for pre-releases published from draft releases, but the `published` type will trigger. If you want a workflow to run when stable *and* pre-releases publish, subscribe to `published` instead of `released` and `prereleased`. + +{% endnote %} + +Runs your workflow when release activity in your repository occurs. For information about the release APIs, see "[Release](/graphql/reference/objects#release)" in the GraphQL API documentation or "[Releases](/rest/reference/repos#releases)" in the REST API documentation. + +For example, you can run a workflow when a release has been `published`. + +```yaml +on: + release: + types: [published] +``` + +### `repository_dispatch` + +| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` | +| ------------------ | ------------ | ------------ | ------------------| +| [repository_dispatch](/developers/webhooks-and-events/webhooks/webhook-events-and-payloads/#repository_dispatch) | Custom | Last commit on default branch | Default branch | + +{% data reusables.github-actions.branch-requirement %} + +You can use the {% data variables.product.product_name %} API to trigger a webhook event called [`repository_dispatch`](/developers/webhooks-and-events/webhooks/webhook-events-and-payloads/#repository_dispatch) when you want to trigger a workflow for activity that happens outside of {% data variables.product.product_name %}. For more information, see "[Create a repository dispatch event](/rest/reference/repos#create-a-repository-dispatch-event)." + +When you make a request to create a `repository_dispatch` event, you must specify an `event_type` to describe the activity type. By default, all `repository_dispatch` activity types trigger a workflow to run. You can use the `types` keyword to limit your workflow to run when a specific `event_type` value is sent in the `repository_dispatch` webhook payload. + +```yaml +on: + repository_dispatch: + types: [on-demand-test] +``` + +Any data that you send through the `client_payload` parameter will be available in the `github.event` context in your workflow. For example, if you send this request body when you create a repository dispatch event: + +```json +{ + "event_type": "test_result", + "client_payload": { + "passed": false, + "message": "Error: timeout" + } +} +``` + +then you can access the payload in a workflow like this: + +```yaml +on: + repository_dispatch: + types: [test_result] + +jobs: + run_if_failure: + if: {% raw %}${{ !github.event.client_payload.passed }}{% endraw %} + runs-on: ubuntu-latest + steps: + - env: + MESSAGE: {% raw %}${{ github.event.client_payload.message }}{% endraw %} + run: echo $MESSAGE +``` ### `schedule` @@ -52,6 +1264,10 @@ The `schedule` event allows you to trigger a workflow at a scheduled time. | --------------------- | -------------- | ------------ | -------------| | n/a | n/a | Last commit on default branch | Default branch | When the scheduled workflow is set to run. A scheduled workflow uses [POSIX cron syntax](https://pubs.opengroup.org/onlinepubs/9699919799/utilities/crontab.html#tag_20_25_07). For more information, see "[Triggering a workflow with events](/articles/configuring-a-workflow/#triggering-a-workflow-with-events)." | +{% data reusables.actions.schedule-delay %} + +The `schedule` event allows you to trigger a workflow at a scheduled time. + {% data reusables.repositories.actions-scheduled-workflow-example %} Cron syntax has five fields separated by a space, and each field represents a unit of time. @@ -72,9 +1288,9 @@ You can use these operators in any of the five fields: | Operator | Description | Example | | -------- | ----------- | ------- | -| * | Any value | `* * * * *` runs every minute of every day. | +| * | Any value | `15 * * * *` runs at every minute 15 of every hour of every day. | | , | Value list separator | `2,10 4,5 * * *` runs at minute 2 and 10 of the 4th and 5th hour of every day. | -| - | Range of values | `0 4-6 * * *` runs at minute 0 of the 4th, 5th, and 6th hour. | +| - | Range of values | `30 4-6 * * *` runs at minute 30 of the 4th, 5th, and 6th hour. | | / | Step values | `20/15 * * * *` runs every 15 minutes starting from minute 20 through 59 (minutes 20, 35, and 50). | {% note %} @@ -85,39 +1301,103 @@ You can use these operators in any of the five fields: You can use [crontab guru](https://crontab.guru/) to help generate your cron syntax and confirm what time it will run. To help you get started, there is also a list of [crontab guru examples](https://crontab.guru/examples.html). -Notifications for scheduled workflows are sent to the user who last modified the cron syntax in the workflow file. For more information, please see "[Notifications for workflow runs](/actions/guides/about-continuous-integration#notifications-for-workflow-runs)." +Notifications for scheduled workflows are sent to the user who last modified the cron syntax in the workflow file. For more information, see "[Notifications for workflow runs](/actions/guides/about-continuous-integration#notifications-for-workflow-runs)." -## Manual events +### `status` -You can manually trigger workflow runs. To trigger specific workflows in a repository, use the `workflow_dispatch` event. To trigger more than one workflow in a repository and create custom events and event types, use the `repository_dispatch` event. +| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` | +| --------------------- | -------------- | ------------ | -------------| +| [`status`](/developers/webhooks-and-events/webhooks/webhook-events-and-payloads/#status) | n/a | Last commit on default branch | n/a | + +{% data reusables.github-actions.branch-requirement %} + +Runs your workflow when the status of a Git commit changes. For example, commits can be marked as `error`, `failure`, `pending`, or `success`. If you want to provide more details about the status change, you may want to use the [`check_run`](#check_run) event. For information about the commit status APIs, see "[Status](/graphql/reference/objects#statue)" in the GraphQL API documentation or "[Statuses](/rest/reference/commits#commit-statuses)" in the REST API documentation. + +For example, you can run a workflow when the `status` event occurs. + +```yaml +on: + status +``` + +If you want to run a job in your workflow based on the new commit state, you can use the `github.event.state` context. For example, the following workflow triggers when a commit status changes, but the `if_error_or_failure` job only runs if the new commit state is `error` or `failure`. + +```yaml +on: + status +jobs: + if_error_or_failure: + runs-on: ubuntu-latest + if: >- + github.event.state == 'error' || + github.event.state == 'failure' + steps: + - env: + DESCRIPTION: {% raw %}${{ github.event.description }}{% endraw %} + run: | + echo The status is error or failed: $DESCRIPTION +``` + +### `watch` + +| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` | +| --------------------- | -------------- | ------------ | -------------| +| [`watch`](/developers/webhooks-and-events/webhooks/webhook-events-and-payloads/#watch) | - `started` | Last commit on default branch | Default branch | + +{% note %} + +**Note**: {% data reusables.developer-site.multiple_activity_types %} Although only the `started` activity type is supported, specifying the activity type will keep your workflow specific if more activity types are added in the future. For information about each activity type, see "[Webhook events and payloads](/developers/webhooks-and-events/webhooks/webhook-events-and-payloads#watch)." {% data reusables.developer-site.limit_workflow_to_activity_types %} + +{% endnote %} + +{% data reusables.github-actions.branch-requirement %} + +Runs your workflow when the workflow's repository is starred. For information about the pull request APIs, see "[addStar](/graphql/reference/mutations#addstar)" in the GraphQL API documentation or "[Starring](/rest/reference/activity#starring)" in the REST API documentation. + +For example, you can run a workflow when someone stars a repository, which is the `started` activity type for a watch event. + +```yaml +on: + watch: + types: [started] +``` + +{% ifversion fpt or ghes > 3.3 or ghae-issue-4757 or ghec %} + +### `workflow_call` + +| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` | +| ------------------ | ------------ | ------------ | ------------------| +| Same as the caller workflow | n/a | Same as the caller workflow | Same as the caller workflow | + +`workflow_call` is used to indicate that a workflow can be called by another workflow. When a workflow is triggered with the `workflow_call` event, the event playload in the called workflow is the same event payload from the calling workflow. For more information see, "[Reusing workflows](/actions/learn-github-actions/reusing-workflows)." + +The example below only runs the workflow when it's called from another workflow: + +```yaml +on: workflow_call +``` + +{% endif %} ### `workflow_dispatch` | Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` | | ------------------ | ------------ | ------------ | ------------------| -| [workflow_dispatch](/webhooks/event-payloads/#workflow_dispatch) | n/a | Last commit on the `GITHUB_REF` branch | Branch that received dispatch | +| [workflow_dispatch](/developers/webhooks-and-events/webhooks/webhook-events-and-payloads/#workflow_dispatch) | n/a | Last commit on the `GITHUB_REF` branch | Branch that received dispatch | -You can configure custom-defined input properties, default input values, and required inputs for the event directly in your workflow. When the workflow runs, you can access the input values in the `github.event.inputs` context. For more information, see "[Contexts](/actions/learn-github-actions/contexts)." - -You can manually trigger a workflow run using the {% ifversion fpt or ghec %}{% data variables.product.prodname_dotcom %}{% else %}{% data variables.product.product_name %}{% endif %} API and from {% data variables.product.product_name %}. For more information, see "[Manually running a workflow](/actions/managing-workflow-runs/manually-running-a-workflow)." - - When you trigger the event on {% data variables.product.prodname_dotcom %}, you can provide the `ref` and any `inputs` directly on {% data variables.product.prodname_dotcom %}. For more information, see "[Using inputs and outputs with an action](/actions/learn-github-actions/finding-and-customizing-actions#using-inputs-and-outputs-with-an-action)." - - To trigger the custom `workflow_dispatch` webhook event using the REST API, you must send a `POST` request to a {% ifversion fpt or ghec %}{% data variables.product.prodname_dotcom %}{% else %}{% data variables.product.product_name %}{% endif %} API endpoint and provide the `ref` and any required `inputs`. For more information, see the "[Create a workflow dispatch event](/rest/reference/actions/#create-a-workflow-dispatch-event)" REST API endpoint. - -#### Example - -To use the `workflow_dispatch` event, you need to include it as a trigger in your GitHub Actions workflow file. The example below only runs the workflow when it's manually triggered: +To manually trigger a workflow, use the `workflow_dispatch` event. You can manually trigger a workflow run using the {% data variables.product.product_name %} API, {% data variables.product.prodname_cli %}, or {% data variables.product.product_name %} browser interface. For more information, see "[Manually running a workflow](/actions/managing-workflow-runs/manually-running-a-workflow)." ```yaml on: workflow_dispatch ``` -#### Example workflow configuration +#### 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 the `ref` and any `inputs`. When the workflow runs, you can access the input values in the `github.event.inputs` context. For more information, see "[Contexts](/actions/learn-github-actions/contexts)." This example defines the `name` and `home` inputs and prints them using the `github.event.inputs.name` and `github.event.inputs.home` contexts. If a `home` isn't provided, the default value 'The Octoverse' is printed. -{% raw %} ```yaml name: Manually triggered workflow on: @@ -137,712 +1417,63 @@ jobs: runs-on: ubuntu-latest steps: - run: | - echo "Hello ${{ github.event.inputs.name }}!" - echo "- in ${{ github.event.inputs.home }}!" -``` -{% endraw %} - -### `repository_dispatch` - -| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` | -| ------------------ | ------------ | ------------ | ------------------| -| [repository_dispatch](/webhooks/event-payloads/#repository_dispatch) | n/a | Last commit on default branch | Default branch | - -{% data reusables.github-actions.branch-requirement %} - -You can use the {% ifversion fpt or ghec %}{% data variables.product.prodname_dotcom %}{% else %}{% data variables.product.product_name %}{% endif %} API to trigger a webhook event called [`repository_dispatch`](/webhooks/event-payloads/#repository_dispatch) when you want to trigger a workflow for activity that happens outside of {% data variables.product.prodname_dotcom %}. For more information, see "[Create a repository dispatch event](/rest/reference/repos#create-a-repository-dispatch-event)." - -To trigger the custom `repository_dispatch` webhook event, you must send a `POST` request to a {% ifversion fpt or ghec %}{% data variables.product.prodname_dotcom %}{% else %}{% data variables.product.product_name %}{% endif %} API endpoint and provide an `event_type` name to describe the activity type. To trigger a workflow run, you must also configure your workflow to use the `repository_dispatch` event. - -#### Example - -By default, all `event_types` trigger a workflow to run. You can limit your workflow to run when a specific `event_type` value is sent in the `repository_dispatch` webhook payload. You define the event types sent in the `repository_dispatch` payload when you create the repository dispatch event. - -```yaml -on: - repository_dispatch: - types: [opened, deleted] -``` - -{% ifversion fpt or ghes > 3.3 or ghae-issue-4757 or ghec %} -## Workflow reuse events - -`workflow_call` is a keyword used as the value of `on` in a workflow, in the same way as an event. It indicates that a workflow can be called from another workflow. For more information see, "[Reusing workflows](/actions/learn-github-actions/reusing-workflows)." - -### `workflow_call` - -| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` | -| ------------------ | ------------ | ------------ | ------------------| -| Same as the caller workflow | n/a | Same as the caller workflow | Same as the caller workflow | - -#### Example - -To make a workflow reusable it must include `workflow_call` as one of the values of `on`. The example below only runs the workflow when it's called from another workflow: - -```yaml -on: workflow_call -``` -{% endif %} - -## Webhook events - -You can configure your workflow to run when webhook events are generated on {% data variables.product.product_name %}. Some events have more than one activity type that triggers the event. If more than one activity type triggers the event, you can specify which activity types will trigger the workflow to run. For more information, see "[Webhooks](/webhooks)." - -Not all webhook events trigger workflows. For the complete list of available webhook events and their payloads, see "[Webhook events and payloads](/developers/webhooks-and-events/webhook-events-and-payloads)." - -{% ifversion fpt or ghec or ghes > 3.3 or ghae-issue-4968 %} -### `branch_protection_rule` - -Runs your workflow anytime the `branch_protection_rule` event occurs. {% data reusables.developer-site.multiple_activity_types %} For information about the GraphQL API, see "[BranchProtectionRule]({% ifversion ghec %}/free-pro-team@latest{% endif %}/graphql/reference/objects#branchprotectionrule)." - -{% data reusables.github-actions.branch-requirement %} - -| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` | -| --------------------- | -------------- | ------------ | -------------| -| [`branch_protection_rule`](/webhooks/event-payloads/#branch_protection_rule) | - `created`
- `edited`
- `deleted` | Last commit on default branch | Default branch | - -{% data reusables.developer-site.limit_workflow_to_activity_types %} - -For example, you can run a workflow when a branch protection rule has been `created` or `deleted`. - -```yaml -on: - branch_protection_rule: - types: [created, deleted] -``` -{% endif %} - -### `check_run` - -Runs your workflow anytime the `check_run` event occurs. {% data reusables.developer-site.multiple_activity_types %} For information about the REST API, see "[Check runs](/rest/reference/checks#runs)." - -{% data reusables.github-actions.branch-requirement %} - -| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` | -| --------------------- | -------------- | ------------ | -------------| -| [`check_run`](/webhooks/event-payloads/#check_run) | - `created`
- `rerequested`
- `completed` | Last commit on default branch | Default branch | - -{% data reusables.developer-site.limit_workflow_to_activity_types %} - -For example, you can run a workflow when a check run has been `rerequested` or `completed`. - -```yaml -on: - check_run: - types: [rerequested, completed] -``` - -### `check_suite` - -Runs your workflow anytime the `check_suite` event occurs. {% data reusables.developer-site.multiple_activity_types %} For information about the REST API, see "[Check suites](/rest/reference/checks#suites)." - -{% data reusables.github-actions.branch-requirement %} - -{% note %} - -**Note:** To prevent recursive workflows, this event does not trigger workflows if the check suite was created by {% data variables.product.prodname_actions %}. - -{% endnote %} - -| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` | -| --------------------- | -------------- | ------------ | -------------| -| [`check_suite`](/webhooks/event-payloads/#check_suite) | - `completed`
- `requested`
- `rerequested`
| Last commit on default branch | Default branch | - -{% data reusables.developer-site.limit_workflow_to_activity_types %} - -For example, you can run a workflow when a check suite has been `rerequested` or `completed`. - -```yaml -on: - check_suite: - types: [rerequested, completed] -``` - -### `create` - -Runs your workflow anytime someone creates a branch or tag, which triggers the `create` event. For information about the REST API, see "[Create a reference](/rest/reference/git#create-a-reference)." - -| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` | -| --------------------- | -------------- | ------------ | -------------| -| [`create`](/webhooks/event-payloads/#create) | n/a | Last commit on the created branch or tag | Branch or tag created | - -For example, you can run a workflow when the `create` event occurs. - -```yaml -on: - create -``` - -### `delete` - -Runs your workflow anytime someone deletes a branch or tag, which triggers the `delete` event. For information about the REST API, see "[Delete a reference](/rest/reference/git#delete-a-reference)." - -{% data reusables.github-actions.branch-requirement %} - -| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` | -| --------------------- | -------------- | ------------ | -------------| -| [`delete`](/webhooks/event-payloads/#delete) | n/a | Last commit on default branch | Default branch | - -For example, you can run a workflow when the `delete` event occurs. - -```yaml -on: - delete -``` - -### `deployment` - -Runs your workflow anytime someone creates a deployment, which triggers the `deployment` event. Deployments created with a commit SHA may not have a Git ref. For information about the REST API, see "[Deployments](/rest/reference/repos#deployments)." - -| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` | -| --------------------- | -------------- | ------------ | -------------| -| [`deployment`](/webhooks/event-payloads/#deployment) | n/a | Commit to be deployed | Branch or tag to be deployed (empty if commit)| - -For example, you can run a workflow when the `deployment` event occurs. - -```yaml -on: - deployment -``` - -### `deployment_status` - -Runs your workflow anytime a third party provides a deployment status, which triggers the `deployment_status` event. Deployments created with a commit SHA may not have a Git ref. For information about the REST API, see "[Create a deployment status](/rest/reference/deployments#create-a-deployment-status)." - -| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` | -| --------------------- | -------------- | ------------ | -------------| -| [`deployment_status`](/webhooks/event-payloads/#deployment_status) | n/a | Commit to be deployed | Branch or tag to be deployed (empty if commit)| - -For example, you can run a workflow when the `deployment_status` event occurs. - -```yaml -on: - deployment_status -``` - -{% note %} - -**Note:** When a deployment status's state is set to `inactive`, a webhook event will not be created. - -{% endnote %} - -{% ifversion fpt or ghec %} -### `discussion` - -Runs your workflow anytime the `discussion` event occurs. {% data reusables.developer-site.multiple_activity_types %} For information about the GraphQL API, see "[Discussions]({% ifversion ghec %}/free-pro-team@latest{% endif %}/graphql/guides/using-the-graphql-api-for-discussions)." - -{% data reusables.github-actions.branch-requirement %} - -| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` | -| --------------------- | -------------- | ------------ | -------------| -| [`discussion`](/webhooks/event-payloads/#discussion) | - `created`
- `edited`
- `deleted`
- `transferred`
- `pinned`
- `unpinned`
- `labeled`
- `unlabeled`
- `locked`
- `unlocked`
- `category_changed`
- `answered`
- `unanswered` | Last commit on default branch | Default branch | - -{% data reusables.developer-site.limit_workflow_to_activity_types %} - -For example, you can run a workflow when a discussion has been `created`, `edited`, or `answered`. - -```yaml -on: - discussion: - types: [created, edited, answered] -``` - -### `discussion_comment` - -Runs your workflow anytime the `discussion_comment` event occurs. {% data reusables.developer-site.multiple_activity_types %} For information about the GraphQL API, see "[Discussions]({% ifversion ghec %}/free-pro-team@latest{% endif %}/graphql/guides/using-the-graphql-api-for-discussions)." - -{% data reusables.github-actions.branch-requirement %} - -| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` | -| --------------------- | -------------- | ------------ | -------------| -| [`discussion_comment`](/developers/webhooks-and-events/webhook-events-and-payloads#discussion_comment) | - `created`
- `edited`
- `deleted`
| Last commit on default branch | Default branch | - -{% data reusables.developer-site.limit_workflow_to_activity_types %} - -For example, you can run a workflow when an issue comment has been `created` or `deleted`. - -```yaml -on: - discussion_comment: - types: [created, deleted] -``` -{% endif %} - -### `fork` - -Runs your workflow anytime when someone forks a repository, which triggers the `fork` event. For information about the REST API, see "[Create a fork](/rest/reference/repos#create-a-fork)." - -{% data reusables.github-actions.branch-requirement %} - -| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` | -| --------------------- | -------------- | ------------ | -------------| -| [`fork`](/webhooks/event-payloads/#fork) | n/a | Last commit on default branch | Default branch | - -For example, you can run a workflow when the `fork` event occurs. - -```yaml -on: - fork -``` - -### `gollum` - -Runs your workflow when someone creates or updates a Wiki page, which triggers the `gollum` event. - -{% data reusables.github-actions.branch-requirement %} - -| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` | -| --------------------- | -------------- | ------------ | -------------| -| [`gollum`](/webhooks/event-payloads/#gollum) | n/a | Last commit on default branch | Default branch | - -For example, you can run a workflow when the `gollum` event occurs. - -```yaml -on: - gollum -``` - -### `issue_comment` - -Runs your workflow anytime the `issue_comment` event occurs. {% data reusables.developer-site.multiple_activity_types %} For information about the REST API, see "[Issue comments](/developers/webhooks-and-events/webhook-events-and-payloads#issue_comment)." - -{% data reusables.github-actions.branch-requirement %} - -| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` | -| --------------------- | -------------- | ------------ | -------------| -| [`issue_comment`](/developers/webhooks-and-events/webhook-events-and-payloads#issue_comment) | - `created`
- `edited`
- `deleted`
| Last commit on default branch | Default branch | - -{% data reusables.developer-site.limit_workflow_to_activity_types %} - -For example, you can run a workflow when an issue comment has been `created` or `deleted`. - -```yaml -on: - issue_comment: - types: [created, deleted] -``` - -The `issue_comment` event occurs for comments on both issues and pull requests. To determine whether the `issue_comment` event was triggered from an issue or pull request, you can check the event payload for the `issue.pull_request` property and use it as a condition to skip a job. - -For example, you can choose to run the `pr_commented` job when comment events occur in a pull request, and the `issue_commented` job when comment events occur in an issue. - -{% raw %} -```yaml -on: issue_comment - -jobs: - pr_commented: - # This job only runs for pull request comments - name: PR comment - if: ${{ github.event.issue.pull_request }} - runs-on: ubuntu-latest - steps: - - run: | - echo "Comment on PR #${{ github.event.issue.number }}" - - issue_commented: - # This job only runs for issue comments - name: Issue comment - if: ${{ !github.event.issue.pull_request }} - runs-on: ubuntu-latest - steps: - - run: | - echo "Comment on issue #${{ github.event.issue.number }}" -``` -{% endraw %} - -### `issues` - -Runs your workflow anytime the `issues` event occurs. {% data reusables.developer-site.multiple_activity_types %} For information about the REST API, see "[Issues](/rest/reference/issues)." - -{% data reusables.github-actions.branch-requirement %} - -| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` | -| --------------------- | -------------- | ------------ | -------------| -| [`issues`](/webhooks/event-payloads/#issues) | - `opened`
- `edited`
- `deleted`
- `transferred`
- `pinned`
- `unpinned`
- `closed`
- `reopened`
- `assigned`
- `unassigned`
- `labeled`
- `unlabeled`
- `locked`
- `unlocked`
- `milestoned`
- `demilestoned` | Last commit on default branch | Default branch | - -{% data reusables.developer-site.limit_workflow_to_activity_types %} - -For example, you can run a workflow when an issue has been `opened`, `edited`, or `milestoned`. - -```yaml -on: - issues: - types: [opened, edited, milestoned] -``` - -### `label` - -Runs your workflow anytime the `label` event occurs. {% data reusables.developer-site.multiple_activity_types %} For information about the REST API, see "[Labels](/rest/reference/issues#labels)." - -{% data reusables.github-actions.branch-requirement %} - -| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` | -| --------------------- | -------------- | ------------ | -------------| -| [`label`](/webhooks/event-payloads/#label) | - `created`
- `edited`
- `deleted`
| Last commit on default branch | Default branch | - -{% data reusables.developer-site.limit_workflow_to_activity_types %} - -For example, you can run a workflow when a label has been `created` or `deleted`. - -```yaml -on: - label: - types: [created, deleted] -``` - -### `milestone` - -Runs your workflow anytime the `milestone` event occurs. {% data reusables.developer-site.multiple_activity_types %} For information about the REST API, see "[Milestones](/rest/reference/issues#milestones)." - -{% data reusables.github-actions.branch-requirement %} - -| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` | -| --------------------- | -------------- | ------------ | -------------| -| [`milestone`](/webhooks/event-payloads/#milestone) | - `created`
- `closed`
- `opened`
- `edited`
- `deleted`
| Last commit on default branch | Default branch | - -{% data reusables.developer-site.limit_workflow_to_activity_types %} - -For example, you can run a workflow when a milestone has been `opened` or `deleted`. - -```yaml -on: - milestone: - types: [opened, deleted] -``` - -### `page_build` - -Runs your workflow anytime someone pushes to a {% data variables.product.product_name %} Pages-enabled branch, which triggers the `page_build` event. For information about the REST API, see "[Pages](/rest/reference/repos#pages)." - -{% data reusables.github-actions.branch-requirement %} - -| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` | -| --------------------- | -------------- | ------------ | -------------| -| [`page_build`](/webhooks/event-payloads/#page_build) | n/a | Last commit on default branch | n/a | - -For example, you can run a workflow when the `page_build` event occurs. - -```yaml -on: - page_build -``` - -### `project` - -Runs your workflow anytime the `project` event occurs. {% data reusables.developer-site.multiple_activity_types %} For information about the REST API, see "[Projects](/rest/reference/projects)." - -{% data reusables.github-actions.branch-requirement %} - -| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` | -| --------------------- | -------------- | ------------ | -------------| -| [`project`](/webhooks/event-payloads/#project) | - `created`
- `updated`
- `closed`
- `reopened`
- `edited`
- `deleted`
| Last commit on default branch | Default branch | - -{% data reusables.developer-site.limit_workflow_to_activity_types %} - -For example, you can run a workflow when a project has been `created` or `deleted`. - -```yaml -on: - project: - types: [created, deleted] -``` - -### `project_card` - -Runs your workflow anytime the `project_card` event occurs. {% data reusables.developer-site.multiple_activity_types %} For information about the REST API, see "[Project cards](/rest/reference/projects#cards)." - -{% data reusables.github-actions.branch-requirement %} - -| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` | -| --------------------- | -------------- | ------------ | -------------| -| [`project_card`](/webhooks/event-payloads/#project_card) | - `created`
- `moved`
- `converted` to an issue
- `edited`
- `deleted` | Last commit on default branch | Default branch | - -{% data reusables.developer-site.limit_workflow_to_activity_types %} - -For example, you can run a workflow when a project card has been `opened` or `deleted`. - -```yaml -on: - project_card: - types: [created, deleted] -``` - -### `project_column` - -Runs your workflow anytime the `project_column` event occurs. {% data reusables.developer-site.multiple_activity_types %} For information about the REST API, see "[Project columns](/rest/reference/projects#columns)." - -{% data reusables.github-actions.branch-requirement %} - -| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` | -| --------------------- | -------------- | ------------ | -------------| -| [`project_column`](/webhooks/event-payloads/#project_column) | - `created`
- `updated`
- `moved`
- `deleted` | Last commit on default branch | Default branch | - -{% data reusables.developer-site.limit_workflow_to_activity_types %} - -For example, you can run a workflow when a project column has been `created` or `deleted`. - -```yaml -on: - project_column: - types: [created, deleted] -``` - -### `public` - -Runs your workflow anytime someone makes a private repository public, which triggers the `public` event. For information about the REST API, see "[Edit repositories](/rest/reference/repos#edit)." - -{% data reusables.github-actions.branch-requirement %} - -| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` | -| --------------------- | -------------- | ------------ | -------------| -| [`public`](/webhooks/event-payloads/#public) | n/a | Last commit on default branch | Default branch | - -For example, you can run a workflow when the `public` event occurs. - -```yaml -on: - public -``` - -### `pull_request` - -Runs your workflow anytime the `pull_request` event occurs. {% data reusables.developer-site.multiple_activity_types %} For information about the REST API, see "[Pull requests](/rest/reference/pulls)." - -{% note %} - -**Notes:** -- By default, a workflow only runs when a `pull_request`'s activity type is `opened`, `synchronize`, or `reopened`. To trigger workflows for more activity types, use the `types` keyword. -- Workflows will not run on `pull_request` activity if the pull request has a merge conflict. The merge conflict must be resolved first. - -{% endnote %} - -| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` | -| --------------------- | -------------- | ------------ | -------------| -| [`pull_request`](/webhooks/event-payloads/#pull_request) | - `assigned`
- `unassigned`
- `labeled`
- `unlabeled`
- `opened`
- `edited`
- `closed`
- `reopened`
- `synchronize`
- `converted_to_draft`
- `ready_for_review`
- `locked`
- `unlocked`
- `review_requested`
- `review_request_removed`{% ifversion fpt or ghes > 3.0 or ghae or ghec %}
- `auto_merge_enabled`
- `auto_merge_disabled`{% endif %} | Last merge commit on the `GITHUB_REF` branch | PR merge branch `refs/pull/:prNumber/merge` | - -You extend or limit the default activity types using the `types` keyword. For more information, see "[Workflow syntax for {% data variables.product.prodname_actions %}](/articles/workflow-syntax-for-github-actions#onevent_nametypes)." - -For example, you can run a workflow when a pull request has been `assigned`, `opened`, `synchronize`, or `reopened`. - -```yaml -on: - pull_request: - types: [assigned, opened, synchronize, reopened] -``` - -{% data reusables.developer-site.pull_request_forked_repos_link %} - -### `pull_request_review` - -Runs your workflow anytime the `pull_request_review` event occurs. {% data reusables.developer-site.multiple_activity_types %} For information about the REST API, see "[Pull request reviews](/rest/reference/pulls#reviews)." - -| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` | -| --------------------- | -------------- | ------------ | -------------| -| [`pull_request_review`](/webhooks/event-payloads/#pull_request_review) | - `submitted`
- `edited`
- `dismissed` | Last merge commit on the `GITHUB_REF` branch | PR merge branch `refs/pull/:prNumber/merge` | - -{% data reusables.developer-site.limit_workflow_to_activity_types %} - -For example, you can run a workflow when a pull request review has been `edited` or `dismissed`. - -```yaml -on: - pull_request_review: - types: [edited, dismissed] -``` - -{% data reusables.developer-site.pull_request_forked_repos_link %} - -### `pull_request_review_comment` - -Runs your workflow anytime a comment on a pull request's unified diff is modified, which triggers the `pull_request_review_comment` event. {% data reusables.developer-site.multiple_activity_types %} For information about the REST API, see [Review comments](/rest/reference/pulls#comments). - -| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` | -| --------------------- | -------------- | ------------ | -------------| -| [`pull_request_review_comment`](/webhooks/event-payloads/#pull_request_review_comment) | - `created`
- `edited`
- `deleted`| Last merge commit on the `GITHUB_REF` branch | PR merge branch `refs/pull/:prNumber/merge` | - -{% data reusables.developer-site.limit_workflow_to_activity_types %} - -For example, you can run a workflow when a pull request review comment has been `created` or `deleted`. - -```yaml -on: - pull_request_review_comment: - types: [created, deleted] -``` - -{% data reusables.developer-site.pull_request_forked_repos_link %} - -### `pull_request_target` - -This event runs in the context of the base of the pull request, rather than in the merge commit as the `pull_request` event does. This prevents executing unsafe workflow 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 you to do things like create workflows that label and comment on pull requests based on the contents of the event payload. - -{% warning %} - -**Warning:** The `pull_request_target` event is granted a read/write repository token and can access secrets, even when it is triggered from a fork. Although the workflow runs in the context of the base of the pull request, you should make sure that you do not check out, build, or run untrusted code from the pull request with this event. Additionally, any caches share the same scope as the base branch, and to help prevent cache poisoning, you should not save the cache if there is a possibility that the cache contents were altered. For more information, see "[Keeping your GitHub Actions and workflows secure: Preventing pwn requests](https://securitylab.github.com/research/github-actions-preventing-pwn-requests)" on the GitHub Security Lab website. - -{% endwarning %} - -| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` | -| --------------------- | -------------- | ------------ | -------------| -| [`pull_request_target`](/webhooks/event-payloads/#pull_request) | - `assigned`
- `unassigned`
- `labeled`
- `unlabeled`
- `opened`
- `edited`
- `closed`
- `reopened`
- `synchronize`
- `converted_to_draft`
- `ready_for_review`
- `locked`
- `unlocked`
- `review_requested`
- `review_request_removed`{% ifversion fpt or ghes > 3.0 or ghae or ghec %}
- `auto_merge_enabled`
- `auto_merge_disabled`{% endif %} | Last commit on the PR base branch | PR base branch | - -By default, a workflow only runs when a `pull_request_target`'s activity type is `opened`, `synchronize`, or `reopened`. To trigger workflows for more activity types, use the `types` keyword. For more information, see "[Workflow syntax for {% data variables.product.prodname_actions %}](/articles/workflow-syntax-for-github-actions#onevent_nametypes)." - -For example, you can run a workflow when a pull request has been `assigned`, `opened`, `synchronize`, or `reopened`. - -```yaml -on: - pull_request_target: - types: [assigned, opened, synchronize, reopened] -``` - -### `push` - -{% note %} - -**Note:** The webhook payload available to GitHub Actions does not include the `added`, `removed`, and `modified` attributes in the `commit` object. You can retrieve the full commit object using the REST API. For more information, see "[Get a commit](/rest/reference/commits#get-a-commit)". - -{% endnote %} - -Runs your workflow when someone pushes to a repository branch, which triggers the `push` event. - -| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` | -| --------------------- | -------------- | ------------ | -------------| -| [`push`](/webhooks/event-payloads/#push) | n/a | Commit pushed, unless deleting a branch (when it's the default branch) | Updated ref | - -For example, you can run a workflow when the `push` event occurs. - -```yaml -on: - push -``` - -### `registry_package` - -Runs your workflow anytime a package is `published` or `updated`. For more information, see "[Managing packages with {% data variables.product.prodname_registry %}](/github/managing-packages-with-github-packages)." - -| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` | -| --------------------- | -------------- | ------------ | -------------| -| [`registry_package`](/webhooks/event-payloads/#package) | - `published`
- `updated` | Commit of the published package | Branch or tag of the published package | - -{% data reusables.developer-site.limit_workflow_to_activity_types %} - -For example, you can run a workflow when a package has been `published`. - -```yaml -on: - registry_package: - types: [published] -``` - -### `release` - -{% note %} - -**Note:** The `release` event is not triggered for draft releases. - -{% endnote %} - -Runs your workflow anytime the `release` event occurs. {% data reusables.developer-site.multiple_activity_types %} For information about the REST API, see "[Releases](/rest/reference/repos#releases)." - -| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` | -| --------------------- | -------------- | ------------ | -------------| -| [`release`](/webhooks/event-payloads/#release) | - `published`
- `unpublished`
- `created`
- `edited`
- `deleted`
- `prereleased`
- `released` | Last commit in the tagged release | Tag of release | - -{% data reusables.developer-site.limit_workflow_to_activity_types %} - -For example, you can run a workflow when a release has been `published`. - -```yaml -on: - release: - types: [published] -``` - -{% note %} - -**Note:** The `prereleased` type will not trigger for pre-releases published from draft releases, but the `published` type will trigger. If you want a workflow to run when stable *and* pre-releases publish, subscribe to `published` instead of `released` and `prereleased`. - -{% endnote %} - -### `status` - -Runs your workflow anytime the status of a Git commit changes, which triggers the `status` event. For information about the REST API, see [Statuses](/rest/reference/repos#statuses). - -{% data reusables.github-actions.branch-requirement %} - -| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` | -| --------------------- | -------------- | ------------ | -------------| -| [`status`](/webhooks/event-payloads/#status) | n/a | Last commit on default branch | n/a | - -For example, you can run a workflow when the `status` event occurs. - -```yaml -on: - status -``` - -### `watch` - -Runs your workflow anytime the `watch` event occurs. {% data reusables.developer-site.multiple_activity_types %} For information about the REST API, see "[Starring](/rest/reference/activity#starring)." - -{% data reusables.github-actions.branch-requirement %} - -| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` | -| --------------------- | -------------- | ------------ | -------------| -| [`watch`](/webhooks/event-payloads/#watch) | - `started` | Last commit on default branch | Default branch | - -{% data reusables.developer-site.limit_workflow_to_activity_types %} - -For example, you can run a workflow when someone stars a repository, which is the `started` activity type that triggers the watch event. - -```yaml -on: - watch: - types: [started] + echo Hello $NAME! + echo -in $HOME + env: + NAME: {% raw %}${{ github.event.inputs.name }}{% endraw %} + HOME: {% raw %}${{ github.event.inputs.home }}{% endraw %} ``` ### `workflow_run` -{% data reusables.webhooks.workflow_run_desc %} +| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` | +| --------------------- | -------------- | ------------ | -------------| +| [`workflow_run`](/developers/webhooks-and-events/webhooks/webhook-events-and-payloads/#workflow_run) | - `completed`
- `requested` | Last commit on default branch | Default branch | {% note %} -**Notes:** - -* This event will only trigger a workflow run if the workflow file is on the default branch. - -* You can't use `workflow_run` to chain together more than three levels of workflows. For example, if you attempt to trigger five workflows (named `B` to `F`) to run sequentially after an initial workflow `A` has run (that is: `A` → `B` → `C` → `D` → `E` → `F`), workflows `E` and `F` will not be run. +**Note**: {% data reusables.developer-site.multiple_activity_types %} The `requested` activity type does no occur when a workflow is re-run. For information about each activity type, see "[Webhook events and payloads](/developers/webhooks-and-events/webhooks/webhook-events-and-payloads#workflow_run)." {% data reusables.developer-site.limit_workflow_to_activity_types %} {% endnote %} -| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` | -| --------------------- | -------------- | ------------ | -------------| -| [`workflow_run`](/webhooks/event-payloads/#workflow_run) | - `completed`
- `requested` | Last commit on default branch | Default branch | +{% data reusables.github-actions.branch-requirement %} -{% data reusables.developer-site.limit_workflow_to_activity_types %} +{% note %} -If you need to filter branches from this event, you can use `branches` or `branches-ignore`. +**Note:** You can't use `workflow_run` to chain together more than three levels of workflows. For example, if you attempt to trigger five workflows (named `B` to `F`) to run sequentially after an initial workflow `A` has run (that is: `A` → `B` → `C` → `D` → `E` → `F`), workflows `E` and `F` will not be run. + +{% endnote %} + +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 the `workflow_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. ```yaml on: workflow_run: - workflows: ["Run Tests"] - branches: [main] + workflows: [Run Tests] types: - completed - - requested ``` -To run a workflow job conditionally based on the result of the previous workflow run, you can use the [`jobs..if`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idif) or [`jobs..steps[*].if`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idstepsif) conditional combined with the `conclusion` of the previous run. For example: +If you specify multiple `workflows` for the `workflow_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. ```yaml on: workflow_run: - workflows: ["Build"] + 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 the `github.event.workflow_run.conclusion` property. For example, this workflow will run whenever a workflow named "Build" completes, but the `on-success` job will only run if the "Build" workflow succeeded, and the `on-failure` job will only run if the "Build" workflow failed: + +```yaml +on: + workflow_run: + workflows: [Build] types: [completed] jobs: @@ -850,16 +1481,105 @@ jobs: runs-on: ubuntu-latest if: {% raw %}${{ github.event.workflow_run.conclusion == 'success' }}{% endraw %} steps: - ... + - run: echo 'The triggering workflow passed' on-failure: runs-on: ubuntu-latest if: {% raw %}${{ github.event.workflow_run.conclusion == 'failure' }}{% endraw %} steps: - ... + - run: echo 'The triggering workflow failed' ``` -## Triggering new workflows using a personal access token +#### Limiting your workflow to run based on branches -{% data reusables.github-actions.actions-do-not-trigger-workflows %} For more information, see "[Authenticating with the GITHUB_TOKEN](/actions/configuring-and-managing-workflows/authenticating-with-the-github_token)." +You can use the `branches` or `branches-ignore` filter to specify what branches the triggering workflow must run on in order to trigger your workflow. For more information, see "[Workflow syntax for GitHub Actions](/actions/learn-github-actions/workflow-syntax-for-github-actions#onworkflow_runbranchesbranches-ignore)." For example, a workflow with the following trigger will only run when the workflow named `Build` runs on a branch named `canary`. -If you would like to trigger a workflow from a workflow run, you can trigger the event using a personal access token. You'll need to create a personal access token and store it as a secret. To minimize your {% data variables.product.prodname_actions %} usage costs, ensure that you don't create recursive or unintended workflow runs. For more information on storing a personal access token as a secret, see "[Creating and storing encrypted secrets](/actions/configuring-and-managing-workflows/creating-and-storing-encrypted-secrets)." +```yaml +on: + workflow_run: + workflows: [Build] + types: [requested] + branches: [canary] +``` + +#### Using data from the triggering workflow + +You can access the [`workflow_run` event payload](/developers/webhooks-and-events/webhooks/webhook-events-and-payloads#workflow_run) that corresponds to the workflow that triggered your workflow. For example, if your triggering workflow generates artifacts, a workflow triggered with the `workflow_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.) + +```yaml +name: Upload data + +on: + pull_request: + +jobs: + upload: + runs-on: ubuntu-latest + + steps: + - name: Save PR number + env: + PR_NUMBER: {% raw %}${{ github.event.number }}{% endraw %} + run: | + mkdir -p ./pr + echo $PR_NUMBER > ./pr/pr_number + - uses: actions/upload-artifact@v2 + with: + name: pr_number + path: pr/ +``` + +When a run of the above workflow completes, it triggers a run of the following workflow. The following workflow uses the `github.event.workflow_run` context and the {% data variables.product.product_name %} 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. + +```yaml +name: Use the data + +on: + workflow_run: + workflows: [Upload data] + types: + - completed + +jobs: + download: + runs-on: ubuntu-latest + steps: + - name: 'Download artifact' + uses: actions/github-script@v5 + with: + 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', + }); + let fs = require('fs'); + fs.writeFileSync(`${process.env.GITHUB_WORKSPACE}/pr_number.zip`, Buffer.from(download.data)); + + - name: 'Unzip artifact' + run: unzip pr_number.zip + + - name: 'Comment on PR' + uses: actions/github-script@v5 + with: + github-token: {% raw %}${{ secrets.GITHUB_TOKEN }}{% endraw %} + script: | + let fs = require('fs'); + let issue_number = Number(fs.readFileSync('./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!' + }); +``` diff --git a/content/actions/learn-github-actions/understanding-github-actions.md b/content/actions/learn-github-actions/understanding-github-actions.md index 6e69efdfbc..bfa2cb82a6 100644 --- a/content/actions/learn-github-actions/understanding-github-actions.md +++ b/content/actions/learn-github-actions/understanding-github-actions.md @@ -114,7 +114,7 @@ To help you understand how YAML syntax is used to create a workflow file, this s ``` -Specifies the trigger for this workflow. This example uses the push event, so a workflow run is triggered every time someone pushes a change to the repository or merges a pull request. This is triggered by a push to every branch; for examples of syntax that runs only on pushes to specific branches, paths, or tags, see "Workflow syntax for {% data variables.product.prodname_actions %}." +Specifies the trigger for this workflow. This example uses the push event, so a workflow run is triggered every time someone pushes a change to the repository or merges a pull request. This is triggered by a push to every branch; for examples of syntax that runs only on pushes to specific branches, paths, or tags, see "Workflow syntax for {% data variables.product.prodname_actions %}." diff --git a/content/actions/learn-github-actions/workflow-syntax-for-github-actions.md b/content/actions/learn-github-actions/workflow-syntax-for-github-actions.md index e2b3572a62..388d25f539 100644 --- a/content/actions/learn-github-actions/workflow-syntax-for-github-actions.md +++ b/content/actions/learn-github-actions/workflow-syntax-for-github-actions.md @@ -35,74 +35,149 @@ The name of your workflow. {% data variables.product.prodname_dotcom %} displays ## `on..types` -Selects the types of activity that will trigger a workflow run. Most GitHub events are triggered by more than one type of activity. For example, the event for the release resource is triggered when a release is `published`, `unpublished`, `created`, `edited`, `deleted`, or `prereleased`. The `types` keyword enables you to narrow down activity that causes the workflow to run. When only one activity type triggers a webhook event, the `types` keyword is unnecessary. +Selects the types of activity that will trigger a workflow run. Most GitHub events are triggered by more than one type of activity. For example, the `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. You can use an array of event `types`. For more information about each event and their activity types, see "[Events that trigger workflows](/articles/events-that-trigger-workflows#webhook-events)." ```yaml -# Trigger the workflow on release activity on: - release: - # Only use the types keyword to narrow down the activity types that will trigger your workflow. - types: [published, created, edited] + label: + types: [created, edited] ``` -## `on..` +## `on..` -When using the `push` and `pull_request` events, you can configure a workflow to run on specific branches or tags. For a `pull_request` event, only branches and tags on the base are evaluated. If you define only `tags` or only `branches`, the workflow won't run for events affecting the undefined Git ref. +When using the `pull_request` and `pull_request_target` events, you can configure a workflow to run only for pull requests that target specific branches. + +Use 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. + +If you define both `branches`/`branches-ignore` and [`paths`](#onpushpull_requestpull_request_targetpathspaths-ignore), the workflow will only run when both filters are satisfied. + +The `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 "[Filter pattern cheat sheet](#filter-pattern-cheat-sheet)." + +### Example: Including branches + +The 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: + +- A branch named `main` (`refs/heads/main`) +- A branch named `mona/octocat` (`refs/heads/mona/octocat`) +- A branch whose name starts with `releases/`, like `releases/10` (`refs/heads/releases/10`) + +```yaml +on: + pull_request: + # Sequence of patterns matched against refs/heads + branches: + - main + - 'mona/octocat' + - 'releases/**' +``` + +### Example: Excluding branches + +When a pattern matches the `branches-ignore` pattern, the workflow will not run. The 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 unless the pull request is targeting: + +- A branch named `mona/octocat` (`refs/heads/mona/octocat`) +- A branch whose name matches `releases/**-alpha`, like `beta/3-alpha` (`refs/releases/beta/3-alpha`) + +```yaml +on: + pull_request: + # Sequence of patterns matched against refs/heads + branches-ignore: + - 'mona/octocat' + - 'releases/**-alpha' +``` + +### Example: Including and excluding branches + +You 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. + +If 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. + +The order that you define patterns matters. + +- A matching negative pattern (prefixed with `!`) after a positive match will exclude the Git ref. +- A matching positive pattern after a negative match will include the Git ref again. + +The following workflow will run on `pull_request` events for pull requests that target `releases/10` or `releases/beta/mona`, but for pull requests that target `releases/10-alpha` or `releases/beta/3-alpha` because the negative pattern `!releases/**-alpha` follows the positive pattern. + +```yaml +on: + pull_request: + branches: + - 'releases/**' + - '!releases/**-alpha' +``` + +## `on..` + +When using the `push` event, you can configure a workflow to run on specific branches or tags. + +Use 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. + +Use 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. + +If you define only `tags`/`tag-ignore` or only `branches`/`branches-ignore`, the workflow won't run for events affecting the undefined Git ref. If you define neither `tags`/`tag-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`](#onpushpull_requestpull_request_targetpathspaths-ignore), the workflow will only run when both filters are satisfied. The `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 "[Filter pattern cheat sheet](#filter-pattern-cheat-sheet)." ### Example: Including branches and tags -The patterns defined in `branches` and `tags` are evaluated against the Git ref's name. For example, defining the pattern `mona/octocat` in `branches` will match the `refs/heads/mona/octocat` Git ref. The pattern `releases/**` will match the `refs/heads/releases/10` Git ref. +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 to: + +- A branch named `main` (`refs/heads/main`) +- A branch named `mona/octocat` (`refs/heads/mona/octocat`) +- A branch whose name starts with `releases/`, like `releases/10` (`refs/heads/releases/10`) +- A tag named `v2` (`refs/tags/v2`) +- A tag whose name starts with `v1.`, like `v1.9.1` (`refs/tags/v1.9.1`) ```yaml on: push: # Sequence of patterns matched against refs/heads - branches: - # Push events on main branch + branches: - main - # Push events to branches matching refs/heads/mona/octocat - 'mona/octocat' - # Push events to branches matching refs/heads/releases/10 - 'releases/**' # Sequence of patterns matched against refs/tags - tags: - - v1 # Push events to v1 tag - - v1.* # Push events to v1.0, v1.1, and v1.9 tags + tags: + - v2 + - v1.* ``` -### Example: Ignoring branches and tags +### Example: Excluding branches and tags -Anytime a pattern matches the `branches-ignore` or `tags-ignore` pattern, the workflow will not run. The patterns defined in `branches-ignore` and `tags-ignore` are evaluated against the Git ref's name. For example, defining the pattern `mona/octocat` in `branches` will match the `refs/heads/mona/octocat` Git ref. The pattern `releases/**-alpha` in `branches` will match the `refs/releases/beta/3-alpha` Git ref. +When 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: + +- A branch named `mona/octocat` (`refs/heads/mona/octocat`) +- A branch whose name matches `releases/**-alpha`, like `beta/3-alpha` (`refs/releases/beta/3-alpha`) +- A tag named `v2` (`refs/tags/v2`) +- A tag whose name starts with `v1.`, like `v1.9` (`refs/tags/v1.9`) ```yaml on: push: # Sequence of patterns matched against refs/heads - branches-ignore: - # Do not push events to branches matching refs/heads/mona/octocat + branches-ignore: - 'mona/octocat' - # Do not push events to branches matching refs/heads/releases/beta/3-alpha - 'releases/**-alpha' # Sequence of patterns matched against refs/tags - tags-ignore: - - v1.* # Do not push events to tags v1.0, v1.1, and v1.9 + tags-ignore: + - v2 + - v1.* ``` -### Excluding branches and tags +### Example: Including and excluding branches and tags -You can use two types of filters to prevent a workflow from running on pushes and pull requests to tags and branches. -- `branches` or `branches-ignore` - You cannot use both the `branches` and `branches-ignore` filters for the same event in a workflow. Use the `branches` filter when you need to filter branches for positive matches and exclude branches. Use the `branches-ignore` filter when you only need to exclude branch names. -- `tags` or `tags-ignore` - You cannot use both the `tags` and `tags-ignore` filters for the same event in a workflow. Use the `tags` filter when you need to filter tags for positive matches and exclude tags. Use the `tags-ignore` filter when you only need to exclude tag names. +You 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. -### Example: Using positive and negative patterns +If 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. -You can exclude `tags` and `branches` using the `!` character. The order that you define patterns matters. - - A matching negative pattern (prefixed with `!`) after a positive match will exclude the Git ref. - - A matching positive pattern after a negative match will include the Git ref again. +The order that you define patterns matters. + +- A matching negative pattern (prefixed with `!`) after a positive match will exclude the Git ref. +- A matching positive pattern after a negative match will include the Git ref again. The 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. @@ -114,26 +189,19 @@ on: - '!releases/**-alpha' ``` -## `on..paths` +## `on..` -When using the `push` and `pull_request` events, you can configure a workflow to run when at least one file does not match `paths-ignore` or at least one modified file matches the configured `paths`. Path filters are not evaluated for pushes to tags. +When 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. -The `paths-ignore` and `paths` keywords accept glob patterns that use the `*` and `**` wildcard characters to match more than one path name. For more information, see the "[Filter pattern cheat sheet](#filter-pattern-cheat-sheet)." +Use 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. -### Example: Ignoring paths +If you define both `branches`/`branches-ignore` and `paths`, the workflow will only run when both filters are satisfied. -When all the path names match patterns in `paths-ignore`, the workflow will not run. {% data variables.product.prodname_dotcom %} evaluates patterns defined in `paths-ignore` against the path name. A workflow with the following path filter will only run on `push` events that include at least one file outside the `docs` directory at the root of the repository. - -```yaml -on: - push: - paths-ignore: - - 'docs/**' -``` +The `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 "[Filter pattern cheat sheet](#filter-pattern-cheat-sheet)." ### Example: Including paths -If at least one path matches a pattern in the `paths` filter, the workflow runs. To trigger a build anytime you push a JavaScript file, you can use a wildcard pattern. +If 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`). ```yaml on: @@ -142,17 +210,29 @@ on: - '**.js' ``` -### Excluding paths +### Example: Excluding paths -You can exclude paths using two types of filters. You cannot use both of these filters for the same event in a workflow. -- `paths-ignore` - Use the `paths-ignore` filter when you only need to exclude path names. -- `paths` - Use the `paths` filter when you need to filter paths for positive matches and exclude paths. +When 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. -### Example: Using positive and negative patterns +A workflow with the following path filter will only run on `push` events that include at least one file outside the `docs` directory at the root of the repository. -You can exclude `paths` using the `!` character. The order that you define patterns matters: - - A matching negative pattern (prefixed with `!`) after a positive match will exclude the path. - - A matching positive pattern after a negative match will include the path again. +```yaml +on: + push: + paths-ignore: + - 'docs/**' +``` + +### Example: Including and excluding paths + +You can not 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 along with the `!` character to indicate which paths should be excluded. + +If 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. + +The order that you define patterns matters: + +- A matching negative pattern (prefixed with `!`) after a positive match will exclude the path. +- A matching positive pattern after a negative match will include the path again. This 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. @@ -290,6 +370,53 @@ A string identifier to associate with the secret. A boolean specifying whether the secret must be supplied. {% endif %} +## `on.workflow_run.` + +When using the `workflow_run` event, you can specify what branches the triggering workflow must run on in order to trigger your workflow. + +The `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 "[Filter pattern cheat sheet](#filter-pattern-cheat-sheet)." + +For example, a workflow with the following trigger will only run when the workflow named `Build` runs on a branch whose name starts with `releases/`: + +```yaml +on: + workflow_run: + workflows: ["Build"] + types: [requested] + branches: + - 'releases/**' +``` + +A workflow with the following trigger will only run when the workflow named `Build` runs on a branch that is not named `canary`: + +```yaml +on: + workflow_run: + workflows: ["Build"] + types: [requested] + branches-ignore: + - "canary" +``` + +You 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. + +The order that you define patterns matters. + +- A matching negative pattern (prefixed with `!`) after a positive match will exclude the branch. +- A matching positive pattern after a negative match will include the branch again. + +For 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`. + +```yaml +on: + workflow_run: + workflows: ["Build"] + types: [requested] + branches: + - 'releases/**' + - '!releases/**-alpha' +``` + ## `on.workflow_dispatch.inputs` When using the `workflow_dispatch` event, you can optionally specify inputs that are passed to the workflow. @@ -1541,7 +1668,7 @@ The characters `*`, `[`, and `!` are special characters in YAML. If you start a - **/README.md ``` -For more information about branch, tag, and path filter syntax, see "[`on..`](#onpushpull_requestbranchestags)" and "[`on..paths`](#onpushpull_requestpaths)." +For more information about branch, tag, and path filter syntax, see "[`on..`](#onpushbranchestagsbranches-ignoretags-ignore)", "[`on..`](#onpull_requestpull_request_targetbranchesbranches-ignore)", and "[`on..paths`](#onpushpull_requestpull_request_targetpathspaths-ignore)." ### Patterns to match branches and tags diff --git a/content/actions/migrating-to-github-actions/migrating-from-jenkins-to-github-actions.md b/content/actions/migrating-to-github-actions/migrating-from-jenkins-to-github-actions.md index dba3e38286..09e50c0b45 100644 --- a/content/actions/migrating-to-github-actions/migrating-from-jenkins-to-github-actions.md +++ b/content/actions/migrating-to-github-actions/migrating-from-jenkins-to-github-actions.md @@ -64,7 +64,7 @@ Jenkins uses directives to manage _Declarative Pipelines_. These directives defi | [`environment`](https://jenkins.io/doc/book/pipeline/syntax/#environment) | [`jobs..env`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#env)
[`jobs..steps[*].env`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idstepsenv) | | [`options`](https://jenkins.io/doc/book/pipeline/syntax/#parameters) | [`jobs..strategy`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idstrategy)
[`jobs..strategy.fail-fast`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idstrategyfail-fast)
[`jobs..timeout-minutes`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idtimeout-minutes) | | [`parameters`](https://jenkins.io/doc/book/pipeline/syntax/#parameters) | [`inputs`](/actions/creating-actions/metadata-syntax-for-github-actions#inputs)
[`outputs`](/actions/creating-actions/metadata-syntax-for-github-actions#outputs) | -| [`triggers`](https://jenkins.io/doc/book/pipeline/syntax/#triggers) | [`on`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#on)
[`on..types`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#onevent_nametypes)
[on..](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#onpushpull_requestbranchestags)
[on..paths](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#onpushpull_requestpaths) | +| [`triggers`](https://jenkins.io/doc/book/pipeline/syntax/#triggers) | [`on`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#on)
[`on..types`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#onevent_nametypes)
[on..](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#onpushbranchestagsbranches-ignoretags-ignore)
[on..](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#onpull_requestpull_request_targetbranchesbranches-ignore)
[on..paths](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#onpushpull_requestpull_request_targetpathspaths-ignore) | | [`triggers { upstreamprojects() }`](https://jenkins.io/doc/book/pipeline/syntax/#triggers) | [`jobs..needs`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idneeds) | | [Jenkins cron syntax](https://jenkins.io/doc/book/pipeline/syntax/#cron-syntax) | [`on.schedule`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#onschedule) | | [`stage`](https://jenkins.io/doc/book/pipeline/syntax/#stage) | [`jobs.`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_id)
[`jobs..name`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idname) | diff --git a/content/actions/migrating-to-github-actions/migrating-from-travis-ci-to-github-actions.md b/content/actions/migrating-to-github-actions/migrating-from-travis-ci-to-github-actions.md index 2cf18968d5..24854ba998 100644 --- a/content/actions/migrating-to-github-actions/migrating-from-travis-ci-to-github-actions.md +++ b/content/actions/migrating-to-github-actions/migrating-from-travis-ci-to-github-actions.md @@ -102,7 +102,7 @@ jobs: ### Targeting specific branches -Travis CI and {% data variables.product.prodname_actions %} both allow you to target your CI to a specific branch. For more information, see "[Workflow syntax for GitHub Actions](/actions/reference/workflow-syntax-for-github-actions#onpushpull_requestbranchestags)." +Travis CI and {% data variables.product.prodname_actions %} both allow you to target your CI to a specific branch. For more information, see "[Workflow syntax for GitHub Actions](/actions/reference/workflow-syntax-for-github-actions#onpushbranchestagsbranches-ignoretags-ignore)." Below is an example of the syntax for each system: diff --git a/content/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/configuring-code-scanning.md b/content/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/configuring-code-scanning.md index 2122636727..eafbc64c0b 100644 --- a/content/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/configuring-code-scanning.md +++ b/content/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/configuring-code-scanning.md @@ -78,7 +78,7 @@ Additionally, when an `on:push` scan returns results that can be mapped to an op The default {% data variables.product.prodname_codeql_workflow %} uses the `pull_request` event to trigger a code scan on pull requests targeted against the default branch. {% ifversion ghes %}The `pull_request` event is not triggered if the pull request was opened from a private fork.{% else %}If a pull request is from a private fork, the `pull_request` event will only be triggered if you've selected the "Run workflows from fork pull requests" option in the repository settings. For more information, see "[Managing {% data variables.product.prodname_actions %} settings for a repository](/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)."{% endif %} -For more information about the `pull_request` event, see "[Workflow syntax for {% data variables.product.prodname_actions %}](/actions/reference/workflow-syntax-for-github-actions#onpushpull_requestbranchestags)." +For more information about the `pull_request` event, see "[Events that trigger workflows](/actions/learn-github-actions/events-that-trigger-workflows#pull_request)." If you scan pull requests, then the results appear as alerts in a pull request check. For more information, see "[Triaging code scanning alerts in pull requests](/code-security/secure-coding/triaging-code-scanning-alerts-in-pull-requests)." @@ -126,7 +126,7 @@ on: {% endnote %} -For more information about using `on:pull_request:paths-ignore` and `on:pull_request:paths` to determine when a workflow will run for a pull request, see "[Workflow syntax for {% data variables.product.prodname_actions %}](/actions/reference/workflow-syntax-for-github-actions#onpushpull_requestpaths)." +For more information about using `on:pull_request:paths-ignore` and `on:pull_request:paths` to determine when a workflow will run for a pull request, see "[Workflow syntax for {% data variables.product.prodname_actions %}](/actions/reference/workflow-syntax-for-github-actions#onpushpull_requestpull_request_targetpathspaths-ignore)." ### Scanning on a schedule @@ -466,7 +466,7 @@ paths-ignore: **Note**: -* The `paths` and `paths-ignore` keywords, used in the context of the {% data variables.product.prodname_code_scanning %} configuration file, should not be confused with the same keywords when used for `on..paths` in a workflow. When they are used to modify `on.` in a workflow, they determine whether the actions will be run when someone modifies code in the specified directories. For more information, see "[Workflow syntax for {% data variables.product.prodname_actions %}](/actions/reference/workflow-syntax-for-github-actions#onpushpull_requestpaths)." +* The `paths` and `paths-ignore` keywords, used in the context of the {% data variables.product.prodname_code_scanning %} configuration file, should not be confused with the same keywords when used for `on..paths` in a workflow. When they are used to modify `on.` in a workflow, they determine whether the actions will be run when someone modifies code in the specified directories. For more information, see "[Workflow syntax for {% data variables.product.prodname_actions %}](/actions/reference/workflow-syntax-for-github-actions#onpushpull_requestpull_request_targetpathspaths-ignore)." * The filter pattern characters `?`, `+`, `[`, `]`, and `!` are not supported and will be matched literally. * `**` characters can only be at the start or end of a line, or surrounded by slashes, and you can't mix `**` and other characters. For example, `foo/**`, `**/foo`, and `foo/**/bar` are all allowed syntax, but `**foo` isn't. However you can use single stars along with other characters, as shown in the example. You'll need to quote anything that contains a `*` character. @@ -474,7 +474,7 @@ paths-ignore: For compiled languages, if you want to limit {% data variables.product.prodname_code_scanning %} to specific directories in your project, you must specify appropriate build steps in the workflow. The commands you need to use to exclude a directory from the build will depend on your build system. For more information, see "[Configuring the {% data variables.product.prodname_codeql %} workflow for compiled languages](/code-security/secure-coding/configuring-the-codeql-workflow-for-compiled-languages#adding-build-steps-for-a-compiled-language)." -You can quickly analyze small portions of a monorepo when you modify code in specific directories. You'll need to both exclude directories in your build steps and use the `paths-ignore` and `paths` keywords for [`on.`](/actions/reference/workflow-syntax-for-github-actions#onpushpull_requestpaths) in your workflow. +You can quickly analyze small portions of a monorepo when you modify code in specific directories. You'll need to both exclude directories in your build steps and use the `paths-ignore` and `paths` keywords for [`on.`](/actions/reference/workflow-syntax-for-github-actions#onpushpull_requestpull_request_targetpathspaths-ignore) in your workflow. ### Example configuration files diff --git a/content/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/troubleshooting-the-codeql-workflow.md b/content/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/troubleshooting-the-codeql-workflow.md index 92f3ba7c48..f510f52509 100644 --- a/content/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/troubleshooting-the-codeql-workflow.md +++ b/content/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/troubleshooting-the-codeql-workflow.md @@ -180,7 +180,7 @@ The default {% data variables.product.prodname_codeql_workflow %} uses a build m Analysis time is typically proportional to the amount of code being analyzed. You can reduce the analysis time by reducing the amount of code being analyzed at once, for example, by excluding test code, or breaking analysis into multiple workflows that analyze only a subset of your code at a time. -For compiled languages like Java, C, C++, and C#, {% data variables.product.prodname_codeql %} analyzes all of the code which was built during the workflow run. To limit the amount of code being analyzed, build only the code which you wish to analyze by specifying your own build steps in a `run` block. You can combine specifying your own build steps with using the `paths` or `paths-ignore` filters on the `pull_request` and `push` events to ensure that your workflow only runs when specific code is changed. For more information, see "[Workflow syntax for {% data variables.product.prodname_actions %}](/actions/reference/workflow-syntax-for-github-actions#onpushpull_requestpaths)." +For compiled languages like Java, C, C++, and C#, {% data variables.product.prodname_codeql %} analyzes all of the code which was built during the workflow run. To limit the amount of code being analyzed, build only the code which you wish to analyze by specifying your own build steps in a `run` block. You can combine specifying your own build steps with using the `paths` or `paths-ignore` filters on the `pull_request` and `push` events to ensure that your workflow only runs when specific code is changed. For more information, see "[Workflow syntax for {% data variables.product.prodname_actions %}](/actions/reference/workflow-syntax-for-github-actions#onpushpull_requestpull_request_targetpathspaths-ignore)." For languages like Go, JavaScript, Python, and TypeScript, that {% data variables.product.prodname_codeql %} analyzes without compiling the source code, you can specify additional configuration options to limit the amount of code to analyze. For more information, see "[Specifying directories to scan](/code-security/secure-coding/configuring-code-scanning#specifying-directories-to-scan)." diff --git a/content/developers/webhooks-and-events/webhooks/webhook-events-and-payloads.md b/content/developers/webhooks-and-events/webhooks/webhook-events-and-payloads.md index f98ec58b61..4a8e7f5131 100644 --- a/content/developers/webhooks-and-events/webhooks/webhook-events-and-payloads.md +++ b/content/developers/webhooks-and-events/webhooks/webhook-events-and-payloads.md @@ -240,7 +240,7 @@ Webhook events are triggered based on the specificity of the domain you register {% note %} -**Note:** You will not receive a webhook for this event when you push more than three tags at once. +**Note:** You will not receive a webhook for this event when you create more than three tags at once. {% endnote %} @@ -382,7 +382,7 @@ Activity related to a discussion. For more information, see the "[Using the Grap Key | Type | Description ----|------|------------- -`action` |`string` | The action performed. Can be `created`, `edited`, `deleted`, `pinned`, `unpinned`, `locked`, `unlocked`, `transferred`, `category_changed`, `answered`, or `unanswered`. +`action` |`string` | The action performed. Can be `created`, `edited`, `deleted`, `pinned`, `unpinned`, `locked`, `unlocked`, `transferred`, `category_changed`, `answered`, `unanswered`, `labeled`, or `unlabeled`. {% data reusables.webhooks.discussion_desc %} {% data reusables.webhooks.repo_desc_graphql %} {% data reusables.webhooks.org_desc_graphql %} @@ -856,6 +856,38 @@ Key | Type | Description {{ webhookPayloadsForCurrentVersion.ping }} +## project + +{% data reusables.webhooks.project_short_desc %} + +### Availability + +- Repository webhooks +- Organization webhooks +- {% data variables.product.prodname_github_apps %} with the `repository_projects` or `organization_projects` permission + +{% ifversion fpt or ghec %} +{% note %} + +**Note**: This event does not occur for Projects (beta). + +{% endnote %} +{% endif %} + +### Webhook payload object + +{% data reusables.webhooks.project_properties %} +{% data reusables.webhooks.repo_desc %} +{% data reusables.webhooks.org_desc %} +{% data reusables.webhooks.app_desc %} +{% data reusables.webhooks.sender_desc %} + +### Webhook payload example + +{{ webhookPayloadsForCurrentVersion.project.created }} + +{% ifversion fpt or ghes or ghec %} + ## project_card {% data reusables.webhooks.project_card_short_desc %} @@ -866,6 +898,14 @@ Key | Type | Description - Organization webhooks - {% data variables.product.prodname_github_apps %} with the `repository_projects` or `organization_projects` permission +{% ifversion fpt or ghec %} +{% note %} + +**Note**: This event does not occur for Projects (beta). + +{% endnote %} +{% endif %} + ### Webhook payload object {% data reusables.webhooks.project_card_properties %} @@ -900,29 +940,6 @@ Key | Type | Description {{ webhookPayloadsForCurrentVersion.project_column.created }} -## project - -{% data reusables.webhooks.project_short_desc %} - -### Availability - -- Repository webhooks -- Organization webhooks -- {% data variables.product.prodname_github_apps %} with the `repository_projects` or `organization_projects` permission - -### Webhook payload object - -{% data reusables.webhooks.project_properties %} -{% data reusables.webhooks.repo_desc %} -{% data reusables.webhooks.org_desc %} -{% data reusables.webhooks.app_desc %} -{% data reusables.webhooks.sender_desc %} - -### Webhook payload example - -{{ webhookPayloadsForCurrentVersion.project.created }} - -{% ifversion fpt or ghes or ghec %} ## public {% data reusables.webhooks.public_short_desc %} diff --git a/data/reusables/developer-site/pull_request_forked_repos_link.md b/data/reusables/developer-site/pull_request_forked_repos_link.md index eb252d7654..6f9bd3c7db 100644 --- a/data/reusables/developer-site/pull_request_forked_repos_link.md +++ b/data/reusables/developer-site/pull_request_forked_repos_link.md @@ -1,21 +1,23 @@ +#### Workflows in forked repositories + +Workflows don't run in forked repositories by default. You must enable GitHub Actions in the **Actions** tab of the forked repository. + +{% data reusables.actions.forked-secrets %} The `GITHUB_TOKEN` has read-only permissions in forked repositories. For more information, see "[Authenticating with the GITHUB_TOKEN](/actions/configuring-and-managing-workflows/authenticating-with-the-github_token)." + #### Pull request events for forked repositories +For pull requests from a forked repository to the base repository, {% data variables.product.product_name %} sends the `pull_request`, `issue_comment`, `pull_request_review_comment`, `pull_request_review`, and `pull_request_target` events to the base repository. No pull request events occur on the forked repository. + +{% ifversion fpt or ghec %} +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, see "[Approving workflow runs from public forks](/actions/managing-workflow-runs/approving-workflow-runs-from-public-forks)." +{% endif %} + {% note %} **Note:** Workflows do not run on private base repositories when you open a pull request from a forked repository. {% endnote %} -When you create a pull request from a forked repository to the base repository, {% data variables.product.prodname_dotcom %} sends the `pull_request` event to the base repository and no pull request events occur on the forked repository. - -Workflows don't run on forked repositories by default. You must enable GitHub Actions in the **Actions** tab of the forked repository. - -{% ifversion fpt or ghec %} -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, see "[Approving workflow runs from public forks](/actions/managing-workflow-runs/approving-workflow-runs-from-public-forks)." -{% endif %} - -{% data reusables.actions.forked-secrets %} The permissions for the `GITHUB_TOKEN` in forked repositories is read-only. For more information, see "[Authenticating with the GITHUB_TOKEN](/actions/configuring-and-managing-workflows/authenticating-with-the-github_token)." - {% note %} **Note:** Workflows triggered by {% data variables.product.prodname_dependabot %} pull requests are treated as though they are from a forked repository, and are also subject to these restrictions. diff --git a/data/reusables/github-actions/actions-do-not-trigger-workflows.md b/data/reusables/github-actions/actions-do-not-trigger-workflows.md index b7ceafcbbb..4941d69060 100644 --- a/data/reusables/github-actions/actions-do-not-trigger-workflows.md +++ b/data/reusables/github-actions/actions-do-not-trigger-workflows.md @@ -1 +1 @@ -When you use the repository's `GITHUB_TOKEN` to perform tasks on behalf of the {% data variables.product.prodname_actions %} app, events triggered by the `GITHUB_TOKEN` will not create a new workflow run. This 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. +When you use the repository's `GITHUB_TOKEN` to perform tasks, events triggered by the `GITHUB_TOKEN` will not create a new workflow run. This 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. diff --git a/data/reusables/github-actions/actions-on-examples.md b/data/reusables/github-actions/actions-on-examples.md index bb945b991c..c5ae5781a6 100644 --- a/data/reusables/github-actions/actions-on-examples.md +++ b/data/reusables/github-actions/actions-on-examples.md @@ -1,34 +1,75 @@ -## Example: Using a single event +### Using a single event + +For example, a workflow with the following `on` value will run when a push is made to any branch in the workflow's repository: ```yaml -# Triggered when code is pushed to any branch in a repository on: push ``` -## Example: Using a list of events +### Using a multiple events + +You 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: ```yaml -# Triggers the workflow on push or pull request events -on: [push, pull_request] +on: [push, fork] ``` -## Example: Using multiple events with activity types or configuration +If 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. -If you need to specify activity types or configuration for an event, you must configure each event separately. You must append a colon (`:`) to all events, including events without configuration. +### Using activity types + +Some events have activity types that give you more control over when your workflow should run. + +For 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. + +```yaml +on: + label: + types: + - created +``` + +If 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. + +```yaml +on: + issue: + types: + - opened + - labeled +``` + +### Using filters + +Some events have filters that give you more control over when your workflow should run. + +For 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. ```yaml on: - # Trigger the workflow on push or pull request, - # but only for the main branch push: branches: - main - pull_request: + - 'releases/**' +``` + +### Using activity types and filters with multiple events + +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. + +For example, a workflow with the following `on` value will run when: + +- A label is created +- A push is made to the `main` branch in the repository +- A push is made to a {% data variables.product.prodname_pages %}-enabled branch + +```yaml +on: + label: + types: + - created + push: branches: - main - # Also trigger on page_build, as well as release created events page_build: - release: - types: # This configuration does not affect the page_build event above - - created ``` diff --git a/data/reusables/github-actions/branch-paths-filter.md b/data/reusables/github-actions/branch-paths-filter.md new file mode 100644 index 0000000000..a0701b5614 --- /dev/null +++ b/data/reusables/github-actions/branch-paths-filter.md @@ -0,0 +1 @@ +If you use both the `branches` filter and the `paths` filter, the workflow will only run when both filters are satisfied. \ No newline at end of file diff --git a/data/reusables/repositories/actions-scheduled-workflow-example.md b/data/reusables/repositories/actions-scheduled-workflow-example.md index 3dae8f356e..d61c5baa10 100644 --- a/data/reusables/repositories/actions-scheduled-workflow-example.md +++ b/data/reusables/repositories/actions-scheduled-workflow-example.md @@ -1,4 +1,4 @@ -You can schedule a workflow to run at specific UTC times using [POSIX cron syntax](https://pubs.opengroup.org/onlinepubs/9699919799/utilities/crontab.html#tag_20_25_07). 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. +You can schedule a workflow to run at specific UTC times using [POSIX cron syntax](https://pubs.opengroup.org/onlinepubs/9699919799/utilities/crontab.html#tag_20_25_07). Scheduled workflows run on the latest commit on the default or base branch. The shortest interval you can run scheduled workflows is once every 15 minutes. This example triggers the workflow every day at 5:30 and 17:30 UTC: @@ -9,3 +9,22 @@ on: - cron: '30 5,17 * * *' ``` + +A single workflow can be triggered by multiple `schedule` events. You can 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, but skips the `Not on Monday or Wednesday` step on Monday and Wednesday. + +```yaml +on: + schedule: + - cron: '30 5 * * 1,3' + - cron: '30 5 * * 2,4' + +jobs: + test_schedule: + runs-on: ubuntu-latest + steps: + - name: Not on Monday or Wednesday + if: github.event.schedule != '30 5 * * 1,3' + run: echo "This step will be skipped on Monday and Wednesday" + - name: Every time + run: echo "This step will always run" +``` diff --git a/data/reusables/webhooks/create_short_desc.md b/data/reusables/webhooks/create_short_desc.md index 5cf906a338..ce6f4d355d 100644 --- a/data/reusables/webhooks/create_short_desc.md +++ b/data/reusables/webhooks/create_short_desc.md @@ -1 +1 @@ -A Git branch or tag is created. For more information, see the "[Git data](/rest/reference/git)" REST API. +A Git branch or tag is created. For more information, see the "[Git database](/rest/reference/git#create-a-reference)" REST API. diff --git a/data/reusables/webhooks/delete_short_desc.md b/data/reusables/webhooks/delete_short_desc.md index 726e68df82..f514958e94 100644 --- a/data/reusables/webhooks/delete_short_desc.md +++ b/data/reusables/webhooks/delete_short_desc.md @@ -1 +1 @@ -A Git branch or tag is deleted. For more information, see the "[Git data](/rest/reference/git)" REST API. +A Git branch or tag is deleted. For more information, see the "[Git database](/rest/reference/git#delete-a-reference)" REST API. diff --git a/data/reusables/webhooks/deployment_status_short_desc.md b/data/reusables/webhooks/deployment_status_short_desc.md index 5c8fe47344..0205b22199 100644 --- a/data/reusables/webhooks/deployment_status_short_desc.md +++ b/data/reusables/webhooks/deployment_status_short_desc.md @@ -1 +1 @@ -A deployment is created. {% data reusables.webhooks.action_type_desc %} For more information, see the "[deployment statuses](/rest/reference/deployments#list-deployment-statuses)" REST API. +A deployment is created. {% data reusables.webhooks.action_type_desc %} For more information, see the "[deployments](/rest/reference/repos#deployments)" REST API. diff --git a/data/reusables/webhooks/gollum_short_desc.md b/data/reusables/webhooks/gollum_short_desc.md index 3049191763..fb4c736e27 100644 --- a/data/reusables/webhooks/gollum_short_desc.md +++ b/data/reusables/webhooks/gollum_short_desc.md @@ -1 +1 @@ -A wiki page is created or updated. For more information, see the "[About wikis](/communities/documenting-your-project-with-wikis/about-wikis)". +A wiki page is created or updated. For more information, see "[About wikis](/communities/documenting-your-project-with-wikis/about-wikis)." diff --git a/data/reusables/webhooks/issues_short_desc.md b/data/reusables/webhooks/issues_short_desc.md index 3edc02859f..851a1ea93b 100644 --- a/data/reusables/webhooks/issues_short_desc.md +++ b/data/reusables/webhooks/issues_short_desc.md @@ -1 +1 @@ -Activity related to an issue. {% data reusables.webhooks.action_type_desc %} For more information, see the "[issues](/rest/reference/issues#comments)" REST API. +Activity related to an issue. {% data reusables.webhooks.action_type_desc %} For more information, see the "[issues](/rest/reference/issues)" REST API. diff --git a/data/reusables/webhooks/milestone_properties.md b/data/reusables/webhooks/milestone_properties.md index 41365074df..2bd860e8a8 100644 --- a/data/reusables/webhooks/milestone_properties.md +++ b/data/reusables/webhooks/milestone_properties.md @@ -1,6 +1,6 @@ Key | Type | Description ----|------|------------- -`action` |`string` | The action that was performed. Can be one of `created`, `closed`, `opened`, `edited`, or `deleted`. +`action` |`string` | The action that was performed. Can be one of `created`, `closed`, `opened` (a closed milestone is re-opened), `edited`, or `deleted`. `milestone` |`object` | The milestone itself. `changes`|`object`| The changes to the milestone if the action was `edited`. `changes[description][from]`|`string` | The previous version of the description if the action was `edited`. diff --git a/data/reusables/webhooks/status_short_desc.md b/data/reusables/webhooks/status_short_desc.md index 6d835788c9..ca8d0b1bed 100644 --- a/data/reusables/webhooks/status_short_desc.md +++ b/data/reusables/webhooks/status_short_desc.md @@ -1 +1 @@ -When the status of a Git commit changes. {% data reusables.webhooks.action_type_desc %} For more information, see the "[statuses](/rest/reference/repos#statuses)" REST API. +When the status of a Git commit changes. For more information, see the "[statuses](/rest/reference/commits#commit-statuses)" REST API. diff --git a/data/reusables/webhooks/workflow_run_desc.md b/data/reusables/webhooks/workflow_run_desc.md deleted file mode 100644 index 486a20dcd1..0000000000 --- a/data/reusables/webhooks/workflow_run_desc.md +++ /dev/null @@ -1,5 +0,0 @@ -This event occurs when a workflow run is requested or completed, and allows you to execute a workflow based on the finished result of another workflow. A workflow run is triggered regardless of the result of the previous workflow. - -For example, if your `pull_request` workflow generates build artifacts, you can create a new workflow that uses `workflow_run` to analyze the results and add a comment to the original pull request. - -The workflow started by the `workflow_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. diff --git a/data/reusables/webhooks/workflow_run_properties.md b/data/reusables/webhooks/workflow_run_properties.md index 1ff99e14f5..bd5001c6eb 100644 --- a/data/reusables/webhooks/workflow_run_properties.md +++ b/data/reusables/webhooks/workflow_run_properties.md @@ -1,4 +1,4 @@ Key | Type | Description ----|------|------------- `action`|`string` | The action that was performed. Can be one of `requested` or `completed`. -`workflow_run`| `object` | The workflow run. Many `workflow_run` keys, such as `head_branch`, `conclusion`, and `pull_requests` are the same as those in a [`check_suite`](#check_suite) object. +`workflow_run`| `object` | The workflow run. Includes information such as `artifacts_url`, `check_suite_id`, `conclusion`, `head_branch`, and `head_sha`. diff --git a/lib/webhooks/static/dotcom/workflow_dispatch.payload.json b/lib/webhooks/static/dotcom/workflow_dispatch.payload.json index 0b4f17741f..55f3a28d67 100644 --- a/lib/webhooks/static/dotcom/workflow_dispatch.payload.json +++ b/lib/webhooks/static/dotcom/workflow_dispatch.payload.json @@ -2,133 +2,138 @@ "inputs": { "name": "Mona the Octocat" }, - "ref": "refs/heads/master", + "organization": { + "avatar_url": "https://avatars.githubusercontent.com/u/6811672?v=4", + "description": null, + "events_url": "https://api.github.com/orgs/octo-org/events", + "hooks_url": "https://api.github.com/orgs/octo-org/hooks", + "id": 79927191, + "issues_url": "https://api.github.com/orgs/octo-org/issues", + "login": "octo-org", + "members_url": "https://api.github.com/orgs/octo-org/members{/member}", + "node_id": "MDEyOk9yZ2FuaXphdGlvbjY4MTE2NzI", + "public_members_url": "https://api.github.com/orgs/octo-org/public_members{/member}", + "repos_url": "https://api.github.com/orgs/octo-org/repos", + "url": "https://api.github.com/orgs/octo-org" + }, + "ref": "refs/heads/main", "repository": { - "id": 17273051, - "node_id": "MDEwOlJlcG9zaXRvcnkxNzI3MzA1MQ==", - "name": "octo-repo", + "allow_forking": true, + "archive_url": "https://api.github.com/repos/octo-org/octo-repo/{archive_format}{/ref}", + "archived": false, + "assignees_url": "https://api.github.com/repos/octo-org/octo-repo/assignees{/user}", + "blobs_url": "https://api.github.com/repos/octo-org/octo-repo/git/blobs{/sha}", + "branches_url": "https://api.github.com/repos/octo-org/octo-repo/branches{/branch}", + "clone_url": "https://github.com/octo-org/octo-repo.git", + "collaborators_url": "https://api.github.com/repos/octo-org/octo-repo/collaborators{/collaborator}", + "comments_url": "https://api.github.com/repos/octo-org/octo-repo/comments{/number}", + "commits_url": "https://api.github.com/repos/octo-org/octo-repo/commits{/sha}", + "compare_url": "https://api.github.com/repos/octo-org/octo-repo/compare/{base}...{head}", + "contents_url": "https://api.github.com/repos/octo-org/octo-repo/contents/{+path}", + "contributors_url": "https://api.github.com/repos/octo-org/octo-repo/contributors", + "created_at": "2021-08-16T21:34:28Z", + "default_branch": "main", + "deployments_url": "https://api.github.com/repos/octo-org/octo-repo/deployments", + "description": null, + "disabled": false, + "downloads_url": "https://api.github.com/repos/octo-org/octo-repo/downloads", + "events_url": "https://api.github.com/repos/octo-org/octo-repo/events", + "fork": false, + "forks": 1, + "forks_count": 1, + "forks_url": "https://api.github.com/repos/octo-org/octo-repo/forks", "full_name": "octo-org/octo-repo", - "private": true, + "git_commits_url": "https://api.github.com/repos/octo-org/octo-repo/git/commits{/sha}", + "git_refs_url": "https://api.github.com/repos/octo-org/octo-repo/git/refs{/sha}", + "git_tags_url": "https://api.github.com/repos/octo-org/octo-repo/git/tags{/sha}", + "git_url": "git://github.com/octo-org/octo-repo.git", + "has_downloads": true, + "has_issues": true, + "has_pages": false, + "has_projects": true, + "has_wiki": true, + "homepage": null, + "hooks_url": "https://api.github.com/repos/octo-org/octo-repo/hooks", + "html_url": "https://github.com/octo-org/octo-repo", + "id": 6811672, + "is_template": false, + "issue_comment_url": "https://api.github.com/repos/octo-org/octo-repo/issues/comments{/number}", + "issue_events_url": "https://api.github.com/repos/octo-org/octo-repo/issues/events{/number}", + "issues_url": "https://api.github.com/repos/octo-org/octo-repo/issues{/number}", + "keys_url": "https://api.github.com/repos/octo-org/octo-repo/keys{/key_id}", + "labels_url": "https://api.github.com/repos/octo-org/octo-repo/labels{/name}", + "language": null, + "languages_url": "https://api.github.com/repos/octo-org/octo-repo/languages", + "license": null, + "merges_url": "https://api.github.com/repos/octo-org/octo-repo/merges", + "milestones_url": "https://api.github.com/repos/octo-org/octo-repo/milestones{/number}", + "mirror_url": null, + "name": "octo-repo", + "node_id": "MDEwOlJlcG9zaXRvcnkzOTY5ODA4MTI=", + "notifications_url": "https://api.github.com/repos/octo-org/octo-repo/notifications{?since,all,participating}", + "open_issues": 97, + "open_issues_count": 97, "owner": { - "login": "octo-org", - "id": 6811672, - "node_id": "MDEyOk9yZ2FuaXphdGlvbjY4MTE2NzI=", - "avatar_url": "https://avatars3.githubusercontent.com/u/6811672?v=4", - "gravatar_id": "", - "url": "https://api.github.com/users/octo-org", - "html_url": "https://github.com/octo-org", + "avatar_url": "https://avatars.githubusercontent.com/u/6811672?v=4", + "events_url": "https://api.github.com/users/octo-org/events{/privacy}", "followers_url": "https://api.github.com/users/octo-org/followers", "following_url": "https://api.github.com/users/octo-org/following{/other_user}", "gists_url": "https://api.github.com/users/octo-org/gists{/gist_id}", + "gravatar_id": "", + "html_url": "https://github.com/octo-org", + "id": 79927191, + "login": "octo-org", + "node_id": "MDEyOk9yZ2FuaXphdGlvbjY4MTE2NzI9", + "organizations_url": "https://api.github.com/users/octo-org/orgs", + "received_events_url": "https://api.github.com/users/octo-org/received_events", + "repos_url": "https://api.github.com/users/octo-org/repos", + "site_admin": false, "starred_url": "https://api.github.com/users/octo-org/starred{/owner}{/repo}", "subscriptions_url": "https://api.github.com/users/octo-org/subscriptions", - "organizations_url": "https://api.github.com/users/octo-org/orgs", - "repos_url": "https://api.github.com/users/octo-org/repos", - "events_url": "https://api.github.com/users/octo-org/events{/privacy}", - "received_events_url": "https://api.github.com/users/octo-org/received_events", "type": "Organization", - "site_admin": false + "url": "https://api.github.com/users/octo-org" }, - "html_url": "https://github.com/octo-org/octo-repo", - "description": "My first repo on GitHub!", - "fork": false, - "url": "https://api.github.com/repos/octo-org/octo-repo", - "forks_url": "https://api.github.com/repos/octo-org/octo-repo/forks", - "keys_url": "https://api.github.com/repos/octo-org/octo-repo/keys{/key_id}", - "collaborators_url": "https://api.github.com/repos/octo-org/octo-repo/collaborators{/collaborator}", - "teams_url": "https://api.github.com/repos/octo-org/octo-repo/teams", - "hooks_url": "https://api.github.com/repos/octo-org/octo-repo/hooks", - "issue_events_url": "https://api.github.com/repos/octo-org/octo-repo/issues/events{/number}", - "events_url": "https://api.github.com/repos/octo-org/octo-repo/events", - "assignees_url": "https://api.github.com/repos/octo-org/octo-repo/assignees{/user}", - "branches_url": "https://api.github.com/repos/octo-org/octo-repo/branches{/branch}", - "tags_url": "https://api.github.com/repos/octo-org/octo-repo/tags", - "blobs_url": "https://api.github.com/repos/octo-org/octo-repo/git/blobs{/sha}", - "git_tags_url": "https://api.github.com/repos/octo-org/octo-repo/git/tags{/sha}", - "git_refs_url": "https://api.github.com/repos/octo-org/octo-repo/git/refs{/sha}", - "trees_url": "https://api.github.com/repos/octo-org/octo-repo/git/trees{/sha}", - "statuses_url": "https://api.github.com/repos/octo-org/octo-repo/statuses/{sha}", - "languages_url": "https://api.github.com/repos/octo-org/octo-repo/languages", + "private": false, + "pulls_url": "https://api.github.com/repos/octo-org/octo-repo/pulls{/number}", + "pushed_at": "2022-01-07T21:57:21Z", + "releases_url": "https://api.github.com/repos/octo-org/octo-repo/releases{/id}", + "size": 144, + "ssh_url": "git@github.com:octo-org/octo-repo.git", + "stargazers_count": 0, "stargazers_url": "https://api.github.com/repos/octo-org/octo-repo/stargazers", - "contributors_url": "https://api.github.com/repos/octo-org/octo-repo/contributors", + "statuses_url": "https://api.github.com/repos/octo-org/octo-repo/statuses/{sha}", "subscribers_url": "https://api.github.com/repos/octo-org/octo-repo/subscribers", "subscription_url": "https://api.github.com/repos/octo-org/octo-repo/subscription", - "commits_url": "https://api.github.com/repos/octo-org/octo-repo/commits{/sha}", - "git_commits_url": "https://api.github.com/repos/octo-org/octo-repo/git/commits{/sha}", - "comments_url": "https://api.github.com/repos/octo-org/octo-repo/comments{/number}", - "issue_comment_url": "https://api.github.com/repos/octo-org/octo-repo/issues/comments{/number}", - "contents_url": "https://api.github.com/repos/octo-org/octo-repo/contents/{+path}", - "compare_url": "https://api.github.com/repos/octo-org/octo-repo/compare/{base}...{head}", - "merges_url": "https://api.github.com/repos/octo-org/octo-repo/merges", - "archive_url": "https://api.github.com/repos/octo-org/octo-repo/{archive_format}{/ref}", - "downloads_url": "https://api.github.com/repos/octo-org/octo-repo/downloads", - "issues_url": "https://api.github.com/repos/octo-org/octo-repo/issues{/number}", - "pulls_url": "https://api.github.com/repos/octo-org/octo-repo/pulls{/number}", - "milestones_url": "https://api.github.com/repos/octo-org/octo-repo/milestones{/number}", - "notifications_url": "https://api.github.com/repos/octo-org/octo-repo/notifications{?since,all,participating}", - "labels_url": "https://api.github.com/repos/octo-org/octo-repo/labels{/name}", - "releases_url": "https://api.github.com/repos/octo-org/octo-repo/releases{/id}", - "deployments_url": "https://api.github.com/repos/octo-org/octo-repo/deployments", - "created_at": "2014-02-28T02:42:51Z", - "updated_at": "2018-10-10T15:58:51Z", - "pushed_at": "2018-10-10T15:58:47Z", - "git_url": "git://github.com/octo-org/octo-repo.git", - "ssh_url": "git@github.com:octo-org/octo-repo.git", - "clone_url": "https://github.com/octo-org/octo-repo.git", "svn_url": "https://github.com/octo-org/octo-repo", - "homepage": "", - "size": 59, - "stargazers_count": 0, - "watchers_count": 0, - "language": "JavaScript", - "has_issues": true, - "has_projects": true, - "has_downloads": true, - "has_wiki": true, - "has_pages": false, - "forks_count": 1, - "mirror_url": null, - "archived": false, - "open_issues_count": 23, - "license": null, - "forks": 1, - "open_issues": 23, + "tags_url": "https://api.github.com/repos/octo-org/octo-repo/tags", + "teams_url": "https://api.github.com/repos/octo-org/octo-repo/teams", + "topics": [], + "trees_url": "https://api.github.com/repos/octo-org/octo-repo/git/trees{/sha}", + "updated_at": "2022-01-07T21:57:24Z", + "url": "https://api.github.com/repos/octo-org/octo-repo", + "visibility": "public", "watchers": 0, - "default_branch": "master" - }, - "organization": { - "login": "octo-org", - "id": 6811672, - "node_id": "MDEyOk9yZ2FuaXphdGlvbjY4MTE2NzI=", - "url": "https://api.github.com/orgs/octo-org", - "repos_url": "https://api.github.com/orgs/octo-org/repos", - "events_url": "https://api.github.com/orgs/octo-org/events", - "hooks_url": "https://api.github.com/orgs/octo-org/hooks", - "issues_url": "https://api.github.com/orgs/octo-org/issues", - "members_url": "https://api.github.com/orgs/octo-org/members{/member}", - "public_members_url": "https://api.github.com/orgs/octo-org/public_members{/member}", - "avatar_url": "https://avatars3.githubusercontent.com/u/6811672?v=4", - "description": "Working better together!" + "watchers_count": 0 }, "sender": { - "login": "Codertocat", - "id": 21031067, - "node_id": "MDQ6VXNlcjIxMDMxMDY3", - "avatar_url": "https://avatars1.githubusercontent.com/u/21031067?v=4", + "avatar_url": "https://avatars.githubusercontent.com/u/25328854?v=4", + "events_url": "https://api.github.com/users/octocat/events{/privacy}", + "followers_url": "https://api.github.com/users/octocat/followers", + "following_url": "https://api.github.com/users/octocat/following{/other_user}", + "gists_url": "https://api.github.com/users/octocat/gists{/gist_id}", "gravatar_id": "", - "url": "https://api.github.com/users/Codertocat", - "html_url": "https://github.com/Codertocat", - "followers_url": "https://api.github.com/users/Codertocat/followers", - "following_url": "https://api.github.com/users/Codertocat/following{/other_user}", - "gists_url": "https://api.github.com/users/Codertocat/gists{/gist_id}", - "starred_url": "https://api.github.com/users/Codertocat/starred{/owner}{/repo}", - "subscriptions_url": "https://api.github.com/users/Codertocat/subscriptions", - "organizations_url": "https://api.github.com/users/Codertocat/orgs", - "repos_url": "https://api.github.com/users/Codertocat/repos", - "events_url": "https://api.github.com/users/Codertocat/events{/privacy}", - "received_events_url": "https://api.github.com/users/Codertocat/received_events", + "html_url": "https://github.com/octocat", + "id": 25328754, + "login": "octocat", + "node_id": "MDQ6VXNlcjI1MzI4ODU0", + "organizations_url": "https://api.github.com/users/octocat/orgs", + "received_events_url": "https://api.github.com/users/octocat/received_events", + "repos_url": "https://api.github.com/users/octocat/repos", + "site_admin": true, + "starred_url": "https://api.github.com/users/octocat/starred{/owner}{/repo}", + "subscriptions_url": "https://api.github.com/users/octocat/subscriptions", "type": "User", - "site_admin": false + "url": "https://api.github.com/users/octocat" }, "workflow": ".github/workflows/hello-world-workflow.yml" } \ No newline at end of file diff --git a/lib/webhooks/static/dotcom/workflow_run.payload.json b/lib/webhooks/static/dotcom/workflow_run.payload.json index 0151f44ce5..6ec2c04adb 100644 --- a/lib/webhooks/static/dotcom/workflow_run.payload.json +++ b/lib/webhooks/static/dotcom/workflow_run.payload.json @@ -127,5 +127,194 @@ "subscriptions_url": "https://api.github.com/users/Codertocat/subscriptions", "type": "User", "url": "https://api.github.com/users/Codertocat" + }, + "workflow": { + "badge_url": "https://github.com/octo-org/octo-repo/workflows/Manually%20triggered%20workflow/badge.svg", + "created_at": "2021-12-15T20:11:38.000Z", + "html_url": "https://github.com/octo-org/octo-repo/blob/main/.github/workflows/syntax.yml", + "id": 16340987, + "name": "Manually triggered workflow", + "node_id": "W_kwDOF6lyTM4A-Vf7", + "path": ".github/workflows/syntax.yml", + "state": "active", + "updated_at": "2021-12-16T18:40:41.000Z", + "url": "https://api.github.com/repos/octo-org/octo-repo/actions/workflows/16340987" + }, + "workflow_run": { + "artifacts_url": "https://api.github.com/repos/octo-org/octo-repo/actions/runs/1589141559/artifacts", + "cancel_url": "https://api.github.com/repos/octo-org/octo-repo/actions/runs/1589141559/cancel", + "check_suite_id": 4683454167, + "check_suite_node_id": "CS_kwDOF6lyTM8AAAABFyfW1w", + "check_suite_url": "https://api.github.com/repos/octo-org/octo-repo/check-suites/4683454167", + "conclusion": null, + "created_at": "2021-12-16T19:37:22Z", + "event": "workflow_dispatch", + "head_branch": "main", + "head_commit": { + "author": { + "email": "octocat@github.com", + "name": "Mona Lisa" + }, + "committer": { + "email": "noreply@github.com", + "name": "GitHub" + }, + "id": "5779607b49aab1200488439f02372c57b4f75444", + "message": "Update milestone-created.yml", + "timestamp": "2021-12-16T19:37:14Z", + "tree_id": "8181cee091cf9627ac07c3cc4b94c015a1d56706" + }, + "head_repository": { + "archive_url": "https://api.github.com/repos/octo-org/octo-repo/{archive_format}{/ref}", + "assignees_url": "https://api.github.com/repos/octo-org/octo-repo/assignees{/user}", + "blobs_url": "https://api.github.com/repos/octo-org/octo-repo/git/blobs{/sha}", + "branches_url": "https://api.github.com/repos/octo-org/octo-repo/branches{/branch}", + "collaborators_url": "https://api.github.com/repos/octo-org/octo-repo/collaborators{/collaborator}", + "comments_url": "https://api.github.com/repos/octo-org/octo-repo/comments{/number}", + "commits_url": "https://api.github.com/repos/octo-org/octo-repo/commits{/sha}", + "compare_url": "https://api.github.com/repos/octo-org/octo-repo/compare/{base}...{head}", + "contents_url": "https://api.github.com/repos/octo-org/octo-repo/contents/{+path}", + "contributors_url": "https://api.github.com/repos/octo-org/octo-repo/contributors", + "deployments_url": "https://api.github.com/repos/octo-org/octo-repo/deployments", + "description": null, + "downloads_url": "https://api.github.com/repos/octo-org/octo-repo/downloads", + "events_url": "https://api.github.com/repos/octo-org/octo-repo/events", + "fork": false, + "forks_url": "https://api.github.com/repos/octo-org/octo-repo/forks", + "full_name": "octo-org/octo-repo", + "git_commits_url": "https://api.github.com/repos/octo-org/octo-repo/git/commits{/sha}", + "git_refs_url": "https://api.github.com/repos/octo-org/octo-repo/git/refs{/sha}", + "git_tags_url": "https://api.github.com/repos/octo-org/octo-repo/git/tags{/sha}", + "hooks_url": "https://api.github.com/repos/octo-org/octo-repo/hooks", + "html_url": "https://github.com/octo-org/octo-repo", + "id": 396980812, + "issue_comment_url": "https://api.github.com/repos/octo-org/octo-repo/issues/comments{/number}", + "issue_events_url": "https://api.github.com/repos/octo-org/octo-repo/issues/events{/number}", + "issues_url": "https://api.github.com/repos/octo-org/octo-repo/issues{/number}", + "keys_url": "https://api.github.com/repos/octo-org/octo-repo/keys{/key_id}", + "labels_url": "https://api.github.com/repos/octo-org/octo-repo/labels{/name}", + "languages_url": "https://api.github.com/repos/octo-org/octo-repo/languages", + "merges_url": "https://api.github.com/repos/octo-org/octo-repo/merges", + "milestones_url": "https://api.github.com/repos/octo-org/octo-repo/milestones{/number}", + "name": "octo-repo", + "node_id": "MDEwOlJlcG9zaXRvcnkzOTY5ODA4MTI=", + "notifications_url": "https://api.github.com/repos/octo-org/octo-repo/notifications{?since,all,participating}", + "owner": { + "avatar_url": "https://avatars.githubusercontent.com/u/79927191?v=4", + "events_url": "https://api.github.com/users/octo-org/events{/privacy}", + "followers_url": "https://api.github.com/users/octo-org/followers", + "following_url": "https://api.github.com/users/octo-org/following{/other_user}", + "gists_url": "https://api.github.com/users/octo-org/gists{/gist_id}", + "gravatar_id": "", + "html_url": "https://github.com/octo-org", + "id": 79927191, + "login": "octo-org", + "node_id": "MDEyOk9yZ2FuaXphdGlvbjc5OTI3MTkx", + "organizations_url": "https://api.github.com/users/octo-org/orgs", + "received_events_url": "https://api.github.com/users/octo-org/received_events", + "repos_url": "https://api.github.com/users/octo-org/repos", + "site_admin": false, + "starred_url": "https://api.github.com/users/octo-org/starred{/owner}{/repo}", + "subscriptions_url": "https://api.github.com/users/octo-org/subscriptions", + "type": "Organization", + "url": "https://api.github.com/users/octo-org" + }, + "private": true, + "pulls_url": "https://api.github.com/repos/octo-org/octo-repo/pulls{/number}", + "releases_url": "https://api.github.com/repos/octo-org/octo-repo/releases{/id}", + "stargazers_url": "https://api.github.com/repos/octo-org/octo-repo/stargazers", + "statuses_url": "https://api.github.com/repos/octo-org/octo-repo/statuses/{sha}", + "subscribers_url": "https://api.github.com/repos/octo-org/octo-repo/subscribers", + "subscription_url": "https://api.github.com/repos/octo-org/octo-repo/subscription", + "tags_url": "https://api.github.com/repos/octo-org/octo-repo/tags", + "teams_url": "https://api.github.com/repos/octo-org/octo-repo/teams", + "trees_url": "https://api.github.com/repos/octo-org/octo-repo/git/trees{/sha}", + "url": "https://api.github.com/repos/octo-org/octo-repo" + }, + "head_sha": "5779607b49aab1200488439f02372c57b4f75444", + "html_url": "https://github.com/octo-org/octo-repo/actions/runs/1589141559", + "id": 1589141559, + "jobs_url": "https://api.github.com/repos/octo-org/octo-repo/actions/runs/1589141559/jobs", + "logs_url": "https://api.github.com/repos/octo-org/octo-repo/actions/runs/1589141559/logs", + "name": "Manually triggered workflow", + "node_id": "WFR_kwLOF6lyTM5euGA3", + "previous_attempt_url": null, + "pull_requests": [], + "repository": { + "archive_url": "https://api.github.com/repos/octo-org/octo-repo/{archive_format}{/ref}", + "assignees_url": "https://api.github.com/repos/octo-org/octo-repo/assignees{/user}", + "blobs_url": "https://api.github.com/repos/octo-org/octo-repo/git/blobs{/sha}", + "branches_url": "https://api.github.com/repos/octo-org/octo-repo/branches{/branch}", + "collaborators_url": "https://api.github.com/repos/octo-org/octo-repo/collaborators{/collaborator}", + "comments_url": "https://api.github.com/repos/octo-org/octo-repo/comments{/number}", + "commits_url": "https://api.github.com/repos/octo-org/octo-repo/commits{/sha}", + "compare_url": "https://api.github.com/repos/octo-org/octo-repo/compare/{base}...{head}", + "contents_url": "https://api.github.com/repos/octo-org/octo-repo/contents/{+path}", + "contributors_url": "https://api.github.com/repos/octo-org/octo-repo/contributors", + "deployments_url": "https://api.github.com/repos/octo-org/octo-repo/deployments", + "description": null, + "downloads_url": "https://api.github.com/repos/octo-org/octo-repo/downloads", + "events_url": "https://api.github.com/repos/octo-org/octo-repo/events", + "fork": false, + "forks_url": "https://api.github.com/repos/octo-org/octo-repo/forks", + "full_name": "octo-org/octo-repo", + "git_commits_url": "https://api.github.com/repos/octo-org/octo-repo/git/commits{/sha}", + "git_refs_url": "https://api.github.com/repos/octo-org/octo-repo/git/refs{/sha}", + "git_tags_url": "https://api.github.com/repos/octo-org/octo-repo/git/tags{/sha}", + "hooks_url": "https://api.github.com/repos/octo-org/octo-repo/hooks", + "html_url": "https://github.com/octo-org/octo-repo", + "id": 396980812, + "issue_comment_url": "https://api.github.com/repos/octo-org/octo-repo/issues/comments{/number}", + "issue_events_url": "https://api.github.com/repos/octo-org/octo-repo/issues/events{/number}", + "issues_url": "https://api.github.com/repos/octo-org/octo-repo/issues{/number}", + "keys_url": "https://api.github.com/repos/octo-org/octo-repo/keys{/key_id}", + "labels_url": "https://api.github.com/repos/octo-org/octo-repo/labels{/name}", + "languages_url": "https://api.github.com/repos/octo-org/octo-repo/languages", + "merges_url": "https://api.github.com/repos/octo-org/octo-repo/merges", + "milestones_url": "https://api.github.com/repos/octo-org/octo-repo/milestones{/number}", + "name": "octo-repo", + "node_id": "MDEwOlJlcG9zaXRvcnkzOTY5ODA4MTI=", + "notifications_url": "https://api.github.com/repos/octo-org/octo-repo/notifications{?since,all,participating}", + "owner": { + "avatar_url": "https://avatars.githubusercontent.com/u/79927191?v=4", + "events_url": "https://api.github.com/users/octo-org/events{/privacy}", + "followers_url": "https://api.github.com/users/octo-org/followers", + "following_url": "https://api.github.com/users/octo-org/following{/other_user}", + "gists_url": "https://api.github.com/users/octo-org/gists{/gist_id}", + "gravatar_id": "", + "html_url": "https://github.com/octo-org", + "id": 79927191, + "login": "octo-org", + "node_id": "MDEyOk9yZ2FuaXphdGlvbjc5OTI3MTkx", + "organizations_url": "https://api.github.com/users/octo-org/orgs", + "received_events_url": "https://api.github.com/users/octo-org/received_events", + "repos_url": "https://api.github.com/users/octo-org/repos", + "site_admin": false, + "starred_url": "https://api.github.com/users/octo-org/starred{/owner}{/repo}", + "subscriptions_url": "https://api.github.com/users/octo-org/subscriptions", + "type": "Organization", + "url": "https://api.github.com/users/octo-org" + }, + "private": true, + "pulls_url": "https://api.github.com/repos/octo-org/octo-repo/pulls{/number}", + "releases_url": "https://api.github.com/repos/octo-org/octo-repo/releases{/id}", + "stargazers_url": "https://api.github.com/repos/octo-org/octo-repo/stargazers", + "statuses_url": "https://api.github.com/repos/octo-org/octo-repo/statuses/{sha}", + "subscribers_url": "https://api.github.com/repos/octo-org/octo-repo/subscribers", + "subscription_url": "https://api.github.com/repos/octo-org/octo-repo/subscription", + "tags_url": "https://api.github.com/repos/octo-org/octo-repo/tags", + "teams_url": "https://api.github.com/repos/octo-org/octo-repo/teams", + "trees_url": "https://api.github.com/repos/octo-org/octo-repo/git/trees{/sha}", + "url": "https://api.github.com/repos/octo-org/octo-repo" + }, + "rerun_url": "https://api.github.com/repos/octo-org/octo-repo/actions/runs/1589141559/rerun", + "run_attempt": 1, + "run_number": 36, + "run_started_at": "2021-12-16T19:37:22Z", + "status": "queued", + "updated_at": "2021-12-16T19:37:22Z", + "url": "https://api.github.com/repos/octo-org/octo-repo/actions/runs/1589141559", + "workflow_id": 16340987, + "workflow_url": "https://api.github.com/repos/octo-org/octo-repo/actions/workflows/16340987" } } \ No newline at end of file