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

[tuves]

Select Topic Area

Product Feedback

Body

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.

Read more here!

[jason-edstrom]

Do they require the use of GH Apps to work? Can I run a code quality scan job in parallel and break my build down the line as a result of that parallel job?

[jason-edstrom]

I'm assuming required: yes and parallel job: no, based on the wording in the article, which is a bummer. The tools I need to help with this enforcement don't offer GH Apps, and my org does not seem to be too keen on them in the first place.

[N-Usha]

Thanks @jason-edstrom. Currently the feature is enabled only using GitHub Apps that subscribe to the new deployment_protection_rule webhook. However anyone could create a custom GitHub App based protection rule with a custom gating logic on top of the API endpoints that your tools and services could be offering. Hope that helps your scenario.
Also if its ok to share, can you please tell which code quality tools that you use... coz GitHub also is officially partnering with a lot of external services to build official GitHub Apps that can be readily configured as protection rules.

[iEmaz]

Lol

[rajawali57]

Bolehkan anda membantu saya

[DavidBoike]

Why is this limited to GitHub Enterprise?

[N-Usha]

This feature is pivoted around GitHub Environments. While environment secrets, and protection rules are available in public repositories for all products, access to protection rules in private or internal repositories is currently scoped to only GitHub Enterprise. For more information, see "GitHub’s products."

[Yooo-Its-King]

Improvements in the security of posts! This assistance is greatly appreciated.

[itsraza2021]

Its great

[skgautam7889]

Thanks for the information!

[Taiwrash]

Hey folks!

I need help in completing my Actions. I am building an action to participate in the HackGitHub challenge. Dev+GitHub hackathon. Here is my repository for review to publish on Marketplace Repository

[tuves]

Thanks for posting in the GitHub Community, @Taiwrash!

Please post questions like this to our new Programming Help 🧑‍💻 category, which is more appropriate for this type of discussion.

Please review our guidelines about the Programming Help category for more information.

[khitrenovich]

Hi @tuves ,

Thank you for rolling this out, custom protection rules is a great step forward.
I have a use case that is not fully covered with the current flow (or rather requires too many moving parts to be usable) that I want to share.

We have a set of secrets that we want to attach to the protected GHA environment. Most of the workflows that need access to those secrets will require manual approval. However, some workflows (CI pipeline, scheduled daily rebuilds etc) will need automatic access. The new custom protection rules could be handy here - but the complexity of the setup currently prevents us from implementing it. To recap, we need a dedicated org-level GitHub App per repo-specific environment and a dedicated server to process the incoming webhook (which we have to build, deploy and maintain)...

I tried to attach the webhook to a dedicated workflow that listens to the repostory_dispatch events, but the need for the org-level GitHub App is still there, and it's not fully clear how to implement proper authentication mechanism to let GitHub App post to this workflow.

For us, it would be great to have a separate workflow in the same repository act as the deployment approver, without the need to define separate GitHub App and worry about the outgoing and incoming webhooks.

I'm open to discuss that in more details if needed.

Thank you,
Anton.