v2.0.3

v2.0.3

A minor patch that adds the fork_full_name output for dealing with forks and pull requests with this Action

Full Changelog: v2.0.2...v2.0.3

v2.0.2

v2.0.2

This release enables a some additional output relating to repository forks. This will allow users to conditionally trigger workflows or behavior if a branch deploy initiates from a pull request that is from a fork

What's Changed

• Fork Outputs by @GrantBirki in #41

Full Changelog: v2.0.1...v2.0.2

v2.0.1

v2.0.1

This pull request enables the toggling of branch-deployments on forks via an input setting. It also fixes a bug that would not properly deploy pull requests that originate from forked repos.

What's Changed

• Deploy Forks by @GrantBirki in #40

Full Changelog: v2.0.0...v2.0.1

v2.0.0

v2.0.0

This release introduces a great new feature and way for developers to safely release their changes without stepping on each other's toes

Introducing Branch Deployment Locks 🎉

About Deployment Locks

Just like how you can comment .deploy on a pull request to trigger a deployment, you can also comment .lock to lock deployments. This will prevent other users from triggering a deployment. The lock is associated with your GitHub handle, so you will be able to deploy any pull request in the repository and as many times as you want. Any other user who attempts a deployment while your lock is active will get a comment on their PR telling them that a lock is in effect

To release the deployment lock, simply comment .unlock on any pull request in the repository at anytime. Please be aware that other users can run this same command to remove the lock (in case you get offline and forget to do so 😉)

Running .lock --info at any time will retrieve lock details about the current lock (if it exists)

You can read more about deployment locks in this repo here

Happy deployments! 🚀

What's Changed

Below is the detailed list of all the changes that went into this version

Beyond deployment locks, this release also adds a lot of minor fixes, improvements, and additional documentation

• Deploy Locks 🔒 by @GrantBirki in #30
• Deploy lock improvements by @GrantBirki in #31
• Lock output improvements by @GrantBirki in #32
• Sticky Lock Output Improvements by @GrantBirki in #33
• Remove lock after deployment and fixes by @GrantBirki in #34
• Lock docs by @GrantBirki in #35
• Lock flags and alias by @GrantBirki in #36
• Usage Guide by @GrantBirki in #38

Full Changelog: v1.5.0...v2.0.0

v1.5.0

v1.5.0

The main feature of this release is allowing users to have an option when it comes to "up-to-date" branch requirements for deployments. For certain situations, it is not desirable to allow users to trigger branch-deployments if a branch is not "up-to-date" with the target branch.

This release now allows users to set a new input parameter when installing this action: update_branch

This new input parameter can have three different values:

• disabled - The action will not take the state of the branch into consideration when doing deployments
• warn - This is the suggested option. It will exit the workflow and leave a warning comment on the pull request which initiated the workflow. It will tell the user that the branch must be updated in order for a deploy/noop to continue
• force - This option is not suggested due to GitHub Action preventing recursive workflow runs from merge commits that are triggered by other workflows. This option will have the Action force update the branch for you

The default option for this new input parameter is warn and will default to this value if nothing is set

What's Changed

• Enforce Updated Branches (noop mode) by @GrantBirki in #27
• Strict update fixes by @GrantBirki in #28
• update_branch param by @GrantBirki in #29

Full Changelog: v1.4.2...v1.5.0

v1.4.2

v1.4.2

This is a simple release that trims whitespace from the deploy trigger to prevent the regex from failing if a newline is present

What's Changed

• Trim the comment body by @nobe4 in #26

New Contributors

• @nobe4 made their first contribution in #26

Full Changelog: v1.4.1...v1.4.2

v1.4.1

v1.4.1

What's Changed

• Bug Fix - Issue Comment by @GrantBirki in #22
• Update docs and sample workflow by @GrantBirki in #25

Full Changelog: v1.4.0...v1.4.1

v1.4.0

v1.4.0

Unit tests and bug fixes!

What's Changed

Significant changes:

• Tests 🧪 by @GrantBirki in #21 - This PR adds 100% test coverage for the entire Action
• New and improved CI test suite with GitHub Actions to validate the stability of every commit

This release has minor improvements including the following:

• Improved inline comments for developer readability
• Better input validation
• String interpolation bug fixes / typos
• Better condition sorting in if/else blocks

Full Changelog: v1.3.0...v1.4.0

v1.3.0

This release adds a few more conditions regarding CI status checks and required reviews. It also changes the formatting of the comments which this action places on PRs to make them more readable, consistent, and informative

v1.2.0

This release adds better error handling for various exit codes that might cause the branch deploy action to exit early. If the Action exits early, it will set the state to bypass to ensure the "post run" action exits accordingly rather than fail

Full Changelog: v1.1.0...v1.2.0