v9.9.1

What's Changed

• Commit Time Checks 🔒 🕐 by @GrantBirki in #315

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

v9.9.0

What's Changed

• #312 Include deployment started comment id in output by @walkerk1980 in #313
• Bump @types/node from 22.6.1 to 22.7.4 in the npm-dependencies group by @dependabot in #309
• Node Package Updates by @GrantBirki in #314

New Contributors

• @walkerk1980 made their first contribution in #313

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

v9.8.1

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.

• Latest Deployments Pagination by @GrantBirki in #307
• node package updates by @GrantBirki in #308

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

v9.8.0

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/[email protected]
  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

• Bump the github-actions group with 2 updates by @dependabot in #301
• Bump @types/node from 22.5.1 to 22.5.2 in the npm-dependencies group by @dependabot in #302
• Enforced Deployment Order by @GrantBirki in #304
• update all node packages by @GrantBirki in #305

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

v9.7.0

What's Changed

• Lock Branch Validation by @GrantBirki in #299
• update internal node deps by @GrantBirki in #300

Full Changelog: v9...v9.7.0

v9.6.0

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.

• Input Validation by @GrantBirki in #293
• Improve .help command by @GrantBirki in #294
• Node Updates by @GrantBirki in #295

Full Changelog: v9...v9.6.0

v9.5.0

What's Changed

• Bump actions/upload-artifact from 4.3.3 to 4.3.4 in the github-actions group by @dependabot in #285
• Additional Commit SHA Outputs 🔢 by @GrantBirki in #289
• update all node packages by @GrantBirki in #290
• clean up node dependencies by @GrantBirki in #291

Full Changelog: v9...v9.5.0

v9.4.0

What's Changed

• Allow Post Run Labels to be Conditionally Skipped by @GrantBirki in #277
• node deps and package cleanup by @GrantBirki in #278
• Label Improvements by @GrantBirki in #280
• Test Improvements 🧪 by @GrantBirki in #281

Full Changelog: v9...v9.4.0

v9.3.1

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.

• Test Fixes / Improvements by @GrantBirki in #275

Full Changelog: v9...v9.3.1

v9.3.0

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.

---

• Post Deploy Feature Improvements by @GrantBirki in #272
• node package updates by @GrantBirki in #273

---

Full Changelog: v9...v9.3.0