Skip to content

Releases: github/branch-deploy

v9.9.1

21 Oct 22:32
e9ac229
Compare
Choose a tag to compare

What's Changed

Full Changelog: v9.9.0...v9.9.1

v9.9.0

18 Oct 18:17
535e75d
Compare
Choose a tag to compare

What's Changed

New Contributors

Full Changelog: v9.8.1...v9.9.0

v9.8.1

24 Sep 19:19
368e17c
Compare
Choose a tag to compare

What's Changed

A follow-up to the v9.8.0 release to implement GraphQL pagination to make "latest deployment checks" more robust when using enforced deployment order.

Full Changelog: v9.8.0...v9.8.1

v9.8.0

20 Sep 18:42
409f6de
Compare
Choose a tag to compare

Enforced Deployment Order 🚀

Introducing a long requested feature, enforced deployment order...

Summary

This pull request does the following:

  • adds a new enforced_deployment_order input option that can be used to require deployments to take place "in order" and for each to pass before the next one can be triggered
  • adds a new needs_to_be_deployed output that maps to the environments that require successful deployments if a deployment attempt is rejected

Detailed

This feature is one that has been requested by folks internally and externally to GitHub for a long time (over a year). This pull request makes it so that users can now control the order in which deployments are made (if they choose to do so).

This feature is optional and can be enabled by setting, enforced_deployment_order: <env1>,<env2>,<env3>. The value for enforced_deployment_order is a string that is read from left->right with each value separated by commas. Each value in this comma separated list is an environment that you wish to use in an "enforced deployment order". Here is an example:

- uses: github/branch-deploy@vX.X.X
  id: branch-deploy
  with:
    environment_targets: development,staging,production
    enforced_deployment_order: development,staging,production

This means that your project has three environments in total (development,staging,production). The enforced_deployment_order input option specifies that your environments must now be deployed in the order in which they are written. So if you want to deploy to production, you must first have a successful (and active) deployment to development and staging before the branch-deploy Action will allow you to trigger a deployment to production.


For more details, please see the pull request that implemented these changes here or the official documentation.


What's Changed

Full Changelog: v9.7.0...v9.8.0

v9.7.0

31 Aug 18:24
4445cd0
Compare
Choose a tag to compare

What's Changed

Full Changelog: v9...v9.7.0

v9.6.0

09 Aug 20:57
7d3b7d8
Compare
Choose a tag to compare

What's Changed

This release mainly contains one minor change to how a few Action inputs used. Some basic input validation is now applied to them, so if you provide an unexpected Action input, the workflow will now fail and log the correct options for the input for you to use instead.

Full Changelog: v9...v9.6.0

v9.5.0

07 Aug 19:31
c706e33
Compare
Choose a tag to compare

What's Changed

Full Changelog: v9...v9.5.0

v9.4.0

19 Jul 22:07
91f77d0
Compare
Choose a tag to compare

What's Changed

Full Changelog: v9...v9.4.0

v9.3.1

06 Jul 17:49
5ef8752
Compare
Choose a tag to compare

What's Changed

This release includes a minor bug fix in the way that deployment SHAs treat the auto_merge function on deployments. It also includes better test coverage of existing code and some control flow improvements as well.

Full Changelog: v9...v9.3.1

v9.3.0

28 Jun 20:50
2d8b8bc
Compare
Choose a tag to compare

What's Changed

🏷️ Labels! 🏷️

This release introduces a new feature known as "post deployment labels". These labels can be configured via a set of four new Action inputs:

Input Required? Default Description
successful_deploy_labels false "" A comma separated list of labels to add to the pull request when a deployment is successful. Example: "deployed,success"
successful_noop_labels false "" A comma separated list of labels to add to the pull request when a noop deployment is successful. Example: "noop,success"
failed_deploy_labels false "" A comma separated list of labels to add to the pull request when a deployment fails. Example: "failed,deploy-failed"
failed_noop_labels false "" A comma separated list of labels to add to the pull request when a noop deployment fails. Example: "failed,noop-failed"

If you use all (or even some) of these new input options, label will be automatically applied (or removed) from your pull request depending on the resulting state of the deployment.

Here is an example scenario:

  1. Someone runs .noop to start a Terraform plan
  2. The .noop completes successfully so the branch-deploy Action adds the ready-for-review label on your pull request
  3. Your team reviews the PR and approves it
  4. Now you are clear to .deploy 🚀

New Outputs!

This Action now exports additional outputs that can be utilized by subsequent workflow steps:

  • review_decision
  • is_outdated
  • merge_state_status
  • commit_status
  • approved_reviews_count

View the action.yml file in this repo or the main README to learn more about these new outputs

A New Custom Deployment Message Variable!

This release also introduces a new deployment message variable that can be rendered into custom deployment messages:

  • approved_reviews_count

This variable will display the number of approved reviews on the pull request at the time of deployment.



Full Changelog: v9...v9.3.0