v2.1.0

Environment Targets 🌍

This release now supports using environment targets with the branch deploy Action:

• .deploy to production
• .deploy development
• .deploy to development
• etc

See the linked PR below for full changes!

What's Changed

• Environment Targets 🌍 by @GrantBirki in #44

Full Changelog: v2.0.5...v2.1.0

v2.0.5

What's Changed

This release introduces a new admins: input as a feature! Check out the linked PR below to learn how it works

• Admins Feature 👩‍🔬 by @GrantBirki in #42

Full Changelog: v2.0.4...v2.0.5

v2.0.4

v2.0.4

This release fixes a bug that was introduced in patch v2.0.3 that would improperly deploy a branch if triggered from a fork

Full Changelog: v2.0.3...v2.0.4

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