deployments

Subscribe to all “deployments” 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

GitHub Actions – Deployment views across environments (GA)

The new deployment views across environments are now generally available (GA)! 🎉

Previously we have shipped dashboard views to track your deployments using GitHub Actions across various environments.
These views have enabled Developers and DevOps managers to view the full history of deployments in a repository or filter them across environments & workflows to understand their status, duration or address any blockers.

We are now announcing GA for these Deployment Dashboard views along with the following enhancements:

  • Pinning of environments. Ex: You can now “pin” up to 10 of your most critical environments to provide a quick way to view all the deployments rolled out to them.
  • More filters on the views. Ex: You can now drill down to the list of deployments triggered by specific creators with specific deployment statuses and targeting specific environments.

New Deployment views

Learn more about viewing and filtering deployments in your repository through our documentation.

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

See more

Actions – Prevent self-reviews for secure deployments across Actions environments

Actions environments now makes it more secure to review and control deployments using manual approvals.

Previously, any user could trigger a workflow and also manually approve/reject a deployment job targeting a protected environment, if they are a required reviewer.

We are now introducing an option for environment admins to prevent required reviewers from self-reviews to secure deployments targeting their critical environments.
This would enforce that a different reviewer could approve and sign off the deployments, rather than the same user who triggered the run – making the deployments more secure.
Prevent self-reviews

Learn more about securing environments using deployment protection rules.
For questions, visit the GitHub Actions community.
To see what's next for Actions, visit our public roadmap.

See more

Actions – Secure deployment rollouts to protected environments based on select tag patterns

We now allow defining selected tag patterns for securing your deployments that can run against Actions environments.

Previously environments supported 'Protection Rules' for restricting deployments only for selected deployment branches. We are now enhancing this feature for securing deployments based on selected "Deployment branches and tags".

Admins who want to have more secure and controlled deployments can now specify selected tags or tag patterns on their protected environments – Ex: They could now define that only deployments triggered by tags that match the pattern of "releases/*" could deploy to their "Production" environment.
Deployment Branches and Tags

Learn more about securing environments using deployment protection rules.
For questions, visit the GitHub Actions community.
To see what's next for Actions, visit our public roadmap.

See more

GitHub Actions – New dashboard view for deployments across environments (public beta)

Today, we are announcing public beta of the new experience for deployments across environments. 🎉

Developers and DevOps managers can now view and track the full history of deployments in a repository or filter them across environments to:

  • view active deployments across various environments and navigate to the deployment URLs or
  • understand who and what commits, PRs triggered a deployment in a given environment or
  • monitor the deployment status and duration of deployments or
  • trace any deployment to its source workflow and view logs to diagnose any issues or review any pending approvals etc.

New Deployment views

Learn more about viewing deployments in your repository through our documentation and watching this video.

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

See more

GitHub Actions – OIDC integration with AWS no longer requires pinning of intermediate TLS certificates

GitHub Actions – OpenId Connect (OIDC) integration with AWS is now optimized to avoid pinning any intermediary certificate thumbprints.

While configuring GitHub as an OIDC IdP (ID Provider), AWS now secures communication by trusting GitHub Actions’s trusted root certificate authorities (CAs) instead of using a certificate thumbprint to verify GitHub’s IdP server certificate.
This will address and avoid any issues caused due to pinning certificate thumbprints while authenticating from GitHub to AWS using OIDC. No action is needed for GitHub customers.

Learn more about using OIDC with GitHub Actions.

See more

GitHub Actions – Update on OIDC integration with AWS

We have received customers reporting errors with Actions’ OIDC integration with AWS.
This happens for customers who are pinned to a single intermediary thumbprint from the Certificate Authority (CA) of the Actions SSL certificate.

There are two possible intermediary certificates for the Actions SSL certificate and either can be returned by our servers, requiring customers to trust both. This is a known behavior when the intermediary certificates are cross-signed by the CA.

Customers experiencing issues authenticating via OIDC with AWS should configure both thumbprints to be trusted in the AWS portal.
The two known intermediary thumbprints at this time are:

  • 6938fd4d98bab03faadb97b34396831e3780aea1
  • 1c58a3a8518e8759bf075b76b750d4f2df264fcd

Learn more about using OIDC with GitHub Actions.

See more

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.

See more

Required Deployments

You can now require a successful deployment of a branch before its pull request can be merged. This is made possible by a new branch protection setting titled Require deployments to succeed before merging. To enable the setting, create a new branch protection rule for the target branch. Then, select the environments where deployments must succeed before a pull request can be merged, shown here:

image

This will allow you to ensure code is, for example, exercised in a staging or test environment before it's merged to your main branch.

Learn more about protected branches
Learn more about branch protection rules

See more

Deployment review notifications in Microsoft Teams and Slack

Deployment review notifications for your GitHub Actions environments can now be tracked end-to-end using the GitHub app for Microsoft Teams or Slack. You will be notified when a review is pending on your environment, when an approval is completed and you can see the real time status of your deployment.

The following capabilities have been added to our Microsoft Teams and Slack applications:

  1. Deployment review pending notifications for your environments being deployed through GitHub Actions workflow.
  2. Deployment review completed notifications for your environments being deployed through GitHub Actions workflow.
  3. Deployment status notifications for your environments.

For more information visit the GitHub app guidance for Microsoft Teams or for Slack

See more