webhooks

Subscribe to all “webhooks” posts via RSS or follow GitHub Changelog on Twitter to stay updated on everything we ship.

→ ~ cd github-changelog
→ ~/github-changelog|main git log main
showing all changes successfully

Webhook enhancements for environment protection rules

A GitHub Actions workflow run is made up of one or more jobs and each job is associated with a check run. The workflow_job webhook is sent during state transitions of a workflow job. The job state is included in the webhook payload as the action property, which currently takes the values of queued, in_progress, or completed.

With this change, the workflow_job webhook will now support a new waiting state whenever a job is waiting on an environment protection rule, aligning with the waiting state of the corresponding check run. This enables better insight into the progress of a job when using environment protection rules.

In addition, when a job refers to an environment key in its YAML definition, the resulting workflow_job webhook payload will also include a new property, deployment with the metadata about the deployment created by the check run.

Learn more about using environments for deployment Jobs in a Workflow

For questions, visit the GitHub Actions community.

To see what's next for Actions, visit our public roadmap.

See more

Webhook docs generated from the OpenAPI schema

Recently, GitHub added webhooks to our OpenAPI schema. Now, Webhook events and payloads in the GitHub documentation is built from the OpenAPI schema. The schema-generated documentation is more accurate and comprehensive and includes the payload structure for each event and action type.

Currently, the new webhook docs are available for the Free/Pro/Team and GitHub Enterprise Cloud plans. GitHub Enterprise Server and GitHub AE will get the new docs with the next version release.

Do you have ideas for improvement? Open a documentation issue to let us know.

See more

Webhook forwarding in the GitHub CLI (public beta)

We've launched a limited public beta of a new feature in the GitHub CLI: webhook forwarding.

Webhook forwarding makes it easy to test your webhooks integration in your local environment without having to worry about port forwarding.

All it takes to start receiving webhooks locally is one simple command:

gh webhook forward --repo monalisa/hello-world --events issues,pull_request --url http://localhost:4000/webhooks

With webhook forwarding, you can iterate quickly on your integration without having to deploy your code to a test environment.

To request access to the beta program, post in our GitHub Community discussion. We add new beta users on a regular basis. Once you've been added, you will receive an email at the address registered on your GitHub account.

For more details on this new feature, head over to the docs – see "Receiving webhooks with the GitHub CLI".

See more

Merge group webhook event and GitHub Actions workflow trigger

This feature is available to repositories enrolled in the Pull Request Merge Queue beta.

A new webhook event and GitHub Actions workflow trigger (merge_group) makes it easier to run required status checks on merge groups created by merge queue. A merge group includes the changes from one or more pull requests and must pass the status checks required by the target branch.

A merge_group webhook event, which currently has one supported action (checks_requested), is sent after a merge group is created and informs receivers, including GitHub Actions, when status checks are needed on the merge group. The event payload includes head_sha, the commit SHA that should be validated and have status reported on using check runs or commit statuses. For GitHub Actions, status is reported automatically at the conclusion of jobs in the triggered workflow.

To trigger a GitHub Actions workflow for a merge group, the merge_group trigger should be used. The following example triggers on individual pull requests and merge groups targeting the main branch:

# Trigger this workflow on individual pull requests and merge groups that target the `main` branch
on:
  pull_request:
    branches: [ main ]
  merge_group:
    branches: [ main ]

A push event is still sent when a merge group branch is created, and will trigger a GitHub Actions workflow. However, unlike a merge_group event, a push event does not include the target branch of the merge group.

Learn more about using merge queue.

Learn more about the new GitHub Actions merge_group workflow trigger and the merge_group webhook event.

See more

The push webhook payload provides a consistent head_commit on tag creation

When a new tag is created, the push webhook payload will now always include a head_commit object that contains the data of the commit that the new tag points to. In other words, the head_commit object will always contain the commit data of the payload's after commit.

Previously, during tag creation, there were certain circumstances where the head_commit would contain the data of a different commit.

See more