Closed github-product-roadmap closed 6 months ago
🚢 Allow deployments only for selected Tag patterns has shipped: https://github.blog/changelog/2023-10-06-actions-secure-deployment-rollouts-to-protected-environments-based-on-select-tag-patterns/
Leaving open to track for other related releases.
🚢 Prevent self reviews feature has shipped: https://github.blog/changelog/2023-10-16-actions-prevent-self-reviews-for-secure-deployments-across-actions-environments/
Leaving open to track for remaining feature release.
~This is available for GHES 3.11: https://docs.github.com/en/enterprise-server@3.11/admin/release-notes~
This was an error and the feature will actually ship with GHES 3.12.
🚢 This has shipped with GHES 3.12: https://docs.github.com/en/enterprise-server@3.12/admin/release-notes
Summary
We are now shipping a few enhancements around Actions environments guarded by "deployment protection rules" to make it easy for admins to secure their deployment rollouts.
Prevent self-reviews : Actions environments allows required reviewers to provide manual approvals to control deployments across environments. Previously, a user could trigger a workflow and also self-approve a deployment that references an environment where they are one of the required reviewers. We are now introducing an option for environment admins to prevent self-reviews and secure their deployments targeting their critical environments. This would require a different approver to review and sign off the deployments, rather than the same user who triggered the run - making the deployments more secure.
Allow deployments only for selected Tag patterns - Previously we supported Deployment Branches with "Selected Branches" option. We are now enhancing this feature for controlling deployments to an environment based on “selected tag patterns”.
Configurable timeout for protection rules - Currently required reviewers (manual approvals) and other deployment protection rules (including custom protection rules that are powered by GitHub Apps) configured on an environment have a default of 30 days, post which the deployments timeout and will be considered as "failed" deployments. We are now reducing this default to 5 days and allowing it to be configurable upto 15 days as it will help more controlled deployment rollouts.
Intended Outcome
These enhancements will help admins to have more secure and controlled deployments across Environments
How will it work?
Admins who want to have more controlled deployments can now prevent self-reviews, configure Tag patterns to say, allow only Releases/* Tags to deploy to their Production Environment. And also configure that if a reviewer doesn't approve a deployment beyond 5 days, then the deployment would just fail.