v8.1.0

This release introduces two new input options!

• allow_sha_deployments - Enable deployments to exact SHA1 or SHA256 hashes that represent a point-in-time in your commit history
• disable_naked_commands - Prevent naked deploy commands and enforce environment usage in your commands

These new input options can be enabled like so:

- uses: github/[email protected]
  id: branch-deploy
  with:
    allow_sha_deployments: "true" # <-- allow deployments to SHA hashes
    disable_naked_commands: "true" # <-- prevent the use of .deploy without a specific <environment>

Both of these new input options are disabled by default but can be enabled if you choose to do so. Please ensure you read the documentation about each option before toggling them on as they can drastically change the behavior of this Action

Documentation:

• allow_sha_deployments
• disable_naked_commands

What's Changed

• sha deployments by @GrantBirki in #212
• Prevent Naked Deploys by @GrantBirki in #214
• Update Action Workflows by @GrantBirki in #215
• Dependencies by @GrantBirki in #216
• Output msg fixes by @GrantBirki in #217

Thanks to @tiagonbotelho for the SHA deployment suggestion and @mnaser for UX suggestions with disabling "naked commands"

Full Changelog: v8.0.0...v8.1.0

v8.0.0

⚠️ Breaking Change ⚠️

TL;DR: If you are using the production_environment input, add a letter s to the end of it to make it plural 😉

This breaking change only effects users who have production_environment defined as one of their input options. Simply add an "s" to the end of the input option and treat it as a comma separated list of strings. Here is an example:

...
  uses: github/[email protected]
  with:
    trigger: ".deploy"
    environment: "production"
    stable_branch: "main"
-   production_environment: "production"
+   production_environments: "production"

Release Details

This release enables support for multiple production environments. Before this change, the production_environment input value only accepted a single environment. This is not idea for projects that might do something like this:

• .deploy production - Deploys code to the production environment
• .deploy production-eu - Deploys code to a specialized European production environment (think, GDPR)

Since the production_environment input option only takes one value, we cannot set the production-eu environment as "production" via our API call to GitHub (happens inside of this Action for you). However, production-eu is absolutely a production environment, the name even says so!

To solve this, the production_environment input option will be removed and replaced with its plural counterpart -> production_environments (note the trailing s).

Now you can have lots of production environments, like this:

- name: branch-deploy
  id: branch-deploy
  uses: github/[email protected]
  with:
    trigger: ".deploy"
    noop_trigger: ".noop"
    reaction: "eyes"
    environment: "production"
    stable_branch: "main"
    production_environments: "production,production-eu,production-ap" # <-- a comma separated list of environments

What's Changed

• Support Multiple Production Environments by @GrantBirki in #209

Thanks to @mnaser for the feedback around this improvement 🙇

Full Changelog: v7.5.2...v8.0.0

v7.5.2

This release makes internal changes to upgrade the Action to node20 and it also updates all internal node dependencies with npm update

What's Changed

• Upgrade to node20 by @GrantBirki in #206
• update all node dependencies by @GrantBirki in #207

Full Changelog: v7.5.1...v7.5.2

v7.5.1

v7.5.1

This release adds new documentation and squashes a long living bug related to how merge commits are checked when using the "Merge Commit Strategy" workflow. @chrisgavin lent a hand to squash this tricky bug and now the "Merge Commit Strategy" workflow will continue to run as expected, even if you make merge commits into your branch, update your branch, or resolve merge conflicts 🎉.

What's Changed

• Add multi-environment example by @ncalteen in #203
• Simplify identical commit check using tree SHAs. by @chrisgavin in #204
• Identical commit check fixes by @GrantBirki in #205

New Contributors

• @ncalteen made their first contribution in #203
• @chrisgavin made their first contribution in #204

Full Changelog: v7.5.0...v7.5.1

v7.5.0

v7.5.0

@hubot Style Deploy Locking 🔒

This release introduces Hubot Style Deploy Locking (aka sticky deployment locks). Currently, when you run .deploy it creates a lock during the deployment and then releases the lock when the deployment completes. By using the new input option that this release introduces, you can change the deployment locking behavior so that the lock persists even after the deployment finishes.

New Input Options:

• sticky_locks - By default, this value is set to "false".
• sticky_locks_for_noop - By default, this value is set to "false". You should probably leave it disabled unless you have a significant reason to lock an environment due to a .noop style deployment

Example:

- name: branch-deploy
  id: branch-deploy
  uses: github/[email protected]
    with:
      sticky_locks: "true" # <--- enables sticky deployment lock / hubot style deployment locks
      sticky_locks_for_noop: "true" # <--- enables sticky deployment lock / hubot style deployment locks for noop deployments
      # ... other configuration

This option, combined with the "Unlock on Merge" workflow strategy is highly suggested for mission critical projects using this Action to deploy their code to production.

You can learn more about this new method of deployment locking by reading the new documentation 📚.

This release will be internally tested at GitHub before being set to the latest release

What's Changed v7.4.0

• add base_ref output by @GrantBirki in #194
• update docs by @GrantBirki in #197
• Hubot Style Deploy Locking 🔒 by @GrantBirki in #199
• Update docs by @GrantBirki in #200

Full Changelog: v7.3.1...v7.4.0

What's Changed v7.5.0

• Sticky Locks for noop deployments by @GrantBirki in #202

Full Changelog: v7.4.0...v7.5.0

v7.3.1

v7.3.1

This release fixes a bug where a deployment gets denied if reviews are disabled and no CI checks have been defined

Thanks to @redoz for finding this bug!

What's Changed

• Prechecks Fixes by @GrantBirki in #192

---

Full Changelog: v7.3.0...v7.3.1

v7.3.0

v7.3.0

This new release brings life to this Action's log output though the magic of emojis 🔮 and colors 🌈 !

Example 📸 :

This release also does the following (summarized):

• Moves from core.getInput() to core.getBooleanInput() internally (where applicable)
• Updates all internal node packages with npm update
• Further updates internal node packages via updating package pins in package.json
• Slight code performance improvements
• Slight test cleanup
• Adds new GitHub Action's output variables:
  • issue_number - The issue (PR) number which the Action was triggered on
• Adding the octokit retry plugin to additional functions

What's Changed

The pull requests that are baked into this release

• General Improvements by @GrantBirki in #188
• Additional Octokit Retries & Additional Colors 🌈 by @GrantBirki in #189
• Additional msg formatting by @GrantBirki in #190

Full Changelog: v7.2.2...v7.3.0

v7.2.2

v7.2.2

Minor and rare bug fix with .lock commands

This release fixes a rare edge case with the .lock functionality of this Action. If users --reason <message contained any part of the lockInfoFlag flags, then it would think the request is for lock details, and not to claim the actual lock. This was a wacky bug but it is now resolved by just adding a single leading whitespace character to our lockInfoFlag variable.

This release also adds enhanced debug logging for lock related functions that are internal to this Action

What's Changed

• Lock bug by @GrantBirki in #187

Full Changelog: v7.2.1...v7.2.2

v7.2.1

v7.2.1

This release fixes a minor edge case where the "post deploy" step could fail if the request for lockData returned null. Thanks to @malancas for finding this bug!

What's Changed

• Post Deploy Fixes by @GrantBirki in #183

Full Changelog: v7.2.0...v7.2.1

v7.2.0

v7.2.0

This release introduces retries for all Octokit requests. This issue was raised in #180 which pointed out that potential latency was causing the Action to fail when it was trying to add a file to a branch that didn't quite exist yet. This release adds significant improvements for resiliency when making requests to the GitHub API through Octokit retries.

Users do not need to do anything when upgrading to this release and retries will be handled for you out of the box.

Enjoy! 🚀

What's Changed

• Octokit Retries by @GrantBirki in #181

---

Full Changelog: v7.1.0...v7.2.0