v5.0.0

v5.0.0

Environment Specific Locks 🌍 🔒

This release enables a long requested feature, environment locks!

Why?

Currently, there is only one type of lock and it is a global lock. If a user types .lock on a pull request (with this Action), that user will be the only user that can deploy to any environment. This is effectively a global deploy lock and can be quite hindering to teams with multiple deployment environments. For example, if user A comments .lock because they are doing a deployment to production, then user B cannot request a deployment to staging until the deployment lock is removed. This is less than ideal, and this pull request puts all that in the past

How?

The .lock mechanism in this Action is kind of a "neat hack" and has been since its first inception. There isn't really an ideal way of preserving state between two separate Actions. I thought it might be creative to see what sort of atomic operations exist on GitHub and found that a branch push is about the closest you can get. That is what the .lock mechanism first used and still uses with these changes. The main change though, is instead of all locks storing data in a single (kind of global) branch called branch-deploy-lock, it is now multiple branches -> <environment|global>-branch-deploy-lock. This allows for separate environments to be locked on their own and even support a new option for "globally" locking all environments in the project/repository

New Input Option 🆕

This pull request also adds a new input option for this Action -> global_lock_flag: <string>

The global_lock_flag is an optional input and defaults to --global. User's can pass in --global to lock/unlock command to set or remove a global lock which will block all available options.

Example: .lock --reason a major production incident is being investigated --global

Usage 💻

This section documents the new .lock, .unlock, and .wcid information:

.wcid is the shorthand alias for .lock --details - It means "where can I deploy"

• .lock - locks the default environment
• .lock <environment> - locks the designated environment
• .unlock - unlocks the default environment
• .unlock <environment> - unlocks the designated environment
• .lock --global - Where --global is a string set by the user's config. If present, it locks all environments
• .unlock --global - Where --global is a string set by the user's config. If present, it unlocks all environments
• .wcid - checks if there is a deploy lock on the default environment
• .wcid <environment> - checks if there is a deploy lock on the designated environment

It should be noted that if you use any commands such as .lock, .unlock, .lock --details, .wcid, etc without a specified environment, then they will use the whatever environment you have configured as the default in your Action's inputs. This value is usually production and you can see its definition here

Examples 📷

Here are some examples using these new options:

Lock

• .lock <environment>
  • .lock production - Locks the production environment
  • .lock development - Locks the development environment
  • .lock production --reason something is broken -- Locks the production environment with a "reason"
  • .lock --global - Globally lock all available environments (--reason <text> works here too!)

Unlock

• .unlock <environment>
  • .unlock production - Unlocks the production environment
  • .unlock development - Unlocks the development environment
  • .unlock --global - Globally unlock all available environments

Lock Details

• .lock <environment> --details
  • .lock --details production - Check to see if there is a production lock and return it's details if it exists
  • .lock --details - Check to see if there is a "default environment" lock and return it's details if it exists
  • .lock --global --details - Check to see if there is a "global" lock and return it's details if it exists
  • .wcid <blank|environment|--global> - Shorthand alias for getting lock details

Note: .lock -d, .lock --details, .lock --d, .lock --info, .lock -i, .lock --i, and .wcid all do the same thing - source

Example Screenshots 📸

Cannot deploy due to a global deploy lock:

Locks now match useable environments:

Locks details now tell you have to "unlock" the lock that is blocking you:

---

Additional Changes

This pull request has additional changes backed into it as well!

• Improved unit tests throughout the code base
• Improved comment output onto pull requests created by this Action
• Minor bug fixes
• Improved documentation

⚠️ Breaking Changes

It should be noted that all existing locks for a project should be removed before upgrading to this release or you may have unexpected locking behavior.

What's Changed

• Environment Specific Locks 🌍 🔒 by @GrantBirki in #120
• Lock Link Fixes by @GrantBirki in #123
• HAS_HOOKS checks by @GrantBirki in #124

Full Changelog: v4.6.1...v5.0.0