v10.0.0

v10.0.0

v10 of the github/branch-deploy Action is focused around safety, security, and usability improvements 🚀

BREAKING

Please note that even though there are breaking changes listed, the vast majority of users should be able to simply upgrade to github/branch-deploy@v10 without any issues

• The checks input option can now be used with a comma separated list of CI checks if you only want certain checks to be considered "blocking" in terms of deployments. Read more here.
• Pull requests in the CHANGES_REQUESTED state are now treated the same as PRs in the REVIEW_REQUIRED state.
• The structure and content of the pre/post deployment messages (that get written to PRs) has changed to contain more rich information. This isn't really a breaking change, but it could be if you are parsing these comments in some way.
• The deployment payload that gets set to the GitHub API will now contain two new attributes: params and parsed_params
• By default, you can no longer .deploy or .noop a pull request fork unless it has approvals - reference. These changes have been made as an extra safety check against potentially untrusted commits
• You will no longer be able to deploy a pull request if the target branch is not the default branch - reference1 reference2

Key Changes

• You should use ${{ steps.branch-deploy.outputs.sha }} everywhere instead of ${{ steps.branch-deploy.outputs.ref }} - documentation
• The structure of the deployment payload that gets sent to the GitHub API has a few new attributes - documentation
• You can now have fine grained control to include or ignore CI checks that can (or can't) block your deployments - documentation
• The message rendering system for pre/post deployment messages has been greatly improved. It now has many more variables for custom deployment messages and the default structures have been updated a bit - PR reference
• A new input option has been added commit_verification: true that enforces commits to be signed/verified before they can be deployed by this Action - PR reference
• A lot of new outputs have been added so subsequent workflow steps have access to even more rich data related to deployments
• Preventing the ability to deploy a pull request that is not targeting the default branch
• Branch ruleset warning checks - If you have a potential security misconfiguration in your branch rulesets, this Action will loudly warn you about it in the deployment logs
• The sha output is now available on "Merge commit strategy" deployments as well

What's Changed

Here is a full list of changes:

• Docs updates about .noop by @caridinL6 in #324
• Store params and parsed params into deployment payload by @fabn in #325
• Bump the npm-dependencies group with 2 updates by @dependabot in #326
• update all node packages with npm update by @GrantBirki in #327
• Commit Improvements by @GrantBirki in #328
• General Fixes + Dependency Updates by @GrantBirki in #329
• Change docs around ref to point to sha by @GrantBirki in #330
• Fork Deployment Safety 🔒 by @GrantBirki in #331
• Improved Messaging by @GrantBirki in #332
• Commit Verification 🔒 by @GrantBirki in #333
• API Version Headers by @GrantBirki in #334
• total_seconds - Output Variable by @GrantBirki in #335
• node package updates by @GrantBirki in #336
• feat: ignored_checks by @GrantBirki in #337
• General Fixes + More Logging by @GrantBirki in #338
• feat: respect CHANGES_REQUESTED approval state by @GrantBirki in #339
• feat: prevent deployment when the target branch is not the default branch by @GrantBirki in #341
• Branch Ruleset Checks by @GrantBirki in #342
• General Cleanup + SHA outputs for merge deploy mode by @GrantBirki in #343
• Unlock on Merge branch check improvements by @GrantBirki in #344
• bug: Branch Ruleset API call fails when a user/org doesn't have the ruleset feature by @GrantBirki in #345
• Improve commit verification failure text by @GrantBirki in #346

New Contributors

• @caridinL6 made their first contribution in #324

Full Changelog: v9.10.0...v10.0.0

v10.0.0-rc.1

v10.0.0-rc.1 (⚠️ this is a release candidate)

Do not use this release unless you want to live on the edge

BREAKING

Please note that even though there are breaking changes listed, the vast majority of users should be able to simply upgrade to github/branch-deploy@v10 without any issues

• The checks input option can now be used with a comma separated list of CI checks if you only want certain checks to be considered "blocking" in terms of deployments. Read more here.
• Pull requests in the CHANGES_REQUESTED state are now treated the same as PRs in the REVIEW_REQUIRED state.
• The structure and content of the pre/post deployment messages (that get written to PRs) has changed to contain more rich information. This isn't really a breaking change, but it could be if you are parsing these comments in some way.
• The deployment payload that gets set to the GitHub API will now contain two new attributes: params and parsed_params
• By default, you can no longer .deploy or .noop a pull request fork unless it has approvals - reference. These changes have been made as an extra safety check against potentially untrusted commits
• You will no longer be able to deploy a pull request if the target branch is not the default branch - reference1 reference2

Key Changes

• You should use ${{ steps.branch-deploy.outputs.sha }} everywhere instead of ${{ steps.branch-deploy.outputs.ref }} - documentation
• The structure of the deployment payload that gets sent to the GitHub API has a few new attributes - documentation
• You can now have fine grained control to include or ignore CI checks that can (or can't) block your deployments - documentation
• The message rendering system for pre/post deployment messages has been greatly improved. It now has many more variables for custom deployment messages and the default structures have been updated a bit - PR reference
• A new input option has been added commit_verification: true that enforces commits to be signed/verified before they can be deployed by this Action - PR reference
• A lot of new outputs have been added so subsequent workflow steps have access to even more rich data related to deployments
• Preventing the ability to deploy a pull request that is not targeting the default branch
• Branch ruleset warning checks - If you have a potential security misconfiguration in your branch rulesets, this Action will loudly warn you about it in the deployment logs
• The sha output is now available on "Merge commit strategy" deployments as well

What's Changed

Here is a full list of changes:

• Docs updates about .noop by @caridinL6 in #324
• Store params and parsed params into deployment payload by @fabn in #325
• Bump the npm-dependencies group with 2 updates by @dependabot in #326
• update all node packages with npm update by @GrantBirki in #327
• Commit Improvements by @GrantBirki in #328
• General Fixes + Dependency Updates by @GrantBirki in #329
• Change docs around ref to point to sha by @GrantBirki in #330
• Fork Deployment Safety 🔒 by @GrantBirki in #331
• Improved Messaging by @GrantBirki in #332
• Commit Verification 🔒 by @GrantBirki in #333
• API Version Headers by @GrantBirki in #334
• total_seconds - Output Variable by @GrantBirki in #335
• node package updates by @GrantBirki in #336
• feat: ignored_checks by @GrantBirki in #337
• General Fixes + More Logging by @GrantBirki in #338
• feat: respect CHANGES_REQUESTED approval state by @GrantBirki in #339
• feat: prevent deployment when the target branch is not the default branch by @GrantBirki in #341
• Branch Ruleset Checks by @GrantBirki in #342
• General Cleanup + SHA outputs for merge deploy mode by @GrantBirki in #343
• Unlock on Merge branch check improvements by @GrantBirki in #344

New Contributors

• @caridinL6 made their first contribution in #324

Full Changelog: v9.10.0...v10.0.0-rc.1

v9.10.0

What's Changed

This release contains standard dependency updates and a great new feature to add parsed JSON params as a GitHub Actions output. Thanks to @fabn for this great new feature!

• Add parsed_params output by @fabn in #322
• Bump actions/upload-artifact from 4.4.0 to 4.4.3 in the github-actions group by @dependabot in #317
• Bump the npm-dependencies group across 1 directory with 4 updates by @dependabot in #323

New Contributors

• @fabn made their first contribution in #322

Full Changelog: v9...v9.10.0

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