GitHub Actions: Create and share your own deployment protection rules for safe and controlled deployments

GitHub today announced public beta support for custom deployment protection rules for safely rolling out deployments using GitHub Actions.

Custom deployment protection rules are powered by GitHub Apps and can be enabled on any GitHub org/repo/environment to allow external systems to approve or reject deployments.
Each rule evaluates specific conditions in those external systems to assess the readiness of the environments for automated deployments, making them less risky and more robust.

Starting with this public beta, GitHub Enterprise Cloud (GHEC) users can create their own protection rules to control deployment workflows and, if desired, share them by publishing their apps to the GitHub Marketplace.
You could also install official apps for deployment protection rules from various external partners to define security, compliance and governance related conditions in their services that can be used to control deployments with Actions workflows.

Two custom deployment protection rules enabled on a production environment

Learn more about creating and configuring custom deployment protection rules to set up rigorous, streamlined guardrails for your deployments that ensure only the deployments that have passed all quality, security, and manual approval requirements make it to production.

For questions, visit the GitHub Actions community.
To see what's next for Actions, visit our public roadmap.

Pull request merge queue (public beta): API support and recent fixes

As we work towards general availability of pull request merge queue, we want to thank everyone that has provided feedback ❤ (keep it coming!) and let you know about some recent fixes and new API support.

See the public beta announcement to learn more about merge queue and how it can help increase velocity by automating pull request merges into your busiest branches.

🆕 API support

You can now interact with merge queue programmatically using new GraphQL APIs. Add or remove a pull request from the queue, see which pull requests are queued, get details about a queued pull request, and more. For example:

Call the enqueuePullRequest mutation to add a pull request to the queue or dequeuePullRequest to remove a pull request.

Use the mergeQueue field on Repository to list its contents or configuration. Use the mergeQueueEntry field on PullRequest to get details about a queued pull request including its state, position in the queue, estimated time to merge, and more.

🐛 Fixes

Some of the more noteworthy fixes made since the public beta launch:

  • Fixed: GitHub Actions workflows would not trigger on merge_group events in some repos
  • Fixed: failing queued pull request would remain failing even after checks were rerun and and passed
  • Fixed: confusing “pushed a commit that referenced this pull request” message would appear in the timeline
  • Fixed: commits could be pushed to queue-created prep branches (note: these commits were ignored and not merged, but it created confusion for some users)

Get started

Interested in merge queue? Learn how to get started.

Questions or suggestions? Join the conversation in the merge queue public beta discussion.

See more

npm provenance public beta

npm packages built on a cloud CI/CD system (like GitHub Actions) can now publish with provenance, meaning the package has verifiable links back to its source code and build instructions.

The cloud CI/CD system securely communicates this information by sending provenance information in a signed OIDC JWT to Sigstore's public-good servers, which returns a signing certificate that is sent to the registry along with your built package.

Here's an example of how to do a build with provenance in a GitHub Actions workflow:

name: Publish Package to npmjs
on:
 release:
   types: [created]
jobs:
 build:
   runs-on: ubuntu-latest
   permissions:
     contents: read
     id-token: write
   steps:
     - uses: actions/checkout@v3
     - uses: actions/setup-node@v3
       with:
         node-version: '18.x'
         registry-url: 'https://registry.npmjs.org'
     - run: npm install -g npm
     - run: npm ci
     - run: npm publish --provenance --access public
       env:
         NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}

Once published, packages display provenance on the registry website:

Provenance displayed on the registry website

Dependencies with provenance can also be verified from the command line with npm audit signatures.

For more information, see generating provenance.

See more
View all changes