Skip to content

Latest commit

 

History

History
40 lines (28 loc) · 2.75 KB

File metadata and controls

40 lines (28 loc) · 2.75 KB

Hubot Style Deployment Locks 🔒

Wait, what is hubot? - Hubot is GitHub's chatop friend. It has .deploy functionality that is extremely similar to this Action.

By default, if you run a .deploy command, it creates a non-sticky lock that is released as soon as the deployment finishes. This is fine for smaller projects, but if you have dozens or even hundreds of PRs open at the same time (from different people) there is a good chance when your deploy finishes, someone else will run .deploy and wipe out your changes.

By using Hubot Style Deployment Locks, AKA Sticky Deployment Locks, you can ensure that your deployment will not be wiped out by another deployment since the deployment itself will claim the lock.

The largest difference you will notice when using this setting is that .deploy claims a persistent sticky lock when it is invoked. This is helpful when your usual workflow is .lock followed by .deploy. Noop deployments use non-sticky locks unless you also enable sticky_locks_for_noop.

This behavior is not enabled out of the box and you need to enable it in your Actions configuration with sticky_locks: true. The reasoning for this is that you should also configure the "unlock on merge" mode workflow to take full advantage of automatically releasing locks on PR merge. This extra workflow is really quite beneficial as you no longer need to worry about cleaning up locks after a PR is merged. As soon as you merge your PR where you were running deployments from, that PR is considered "done" and the lock is released.

You can still release locks manually with .unlock at any time and so can other users. This is helpful if you need to release a lock that is blocking a deployment from another PR or if you were just testing changes and want to release the lock.

If you want this logic to also apply to noop deployments, enable sticky_locks_for_noop: true. By default, noop deployments do not claim sticky locks because that can leave locks behind after exploratory runs.

Examples

Enabling sticky deployment locks for .deploy commands:

- name: branch-deploy
  id: branch-deploy
  uses: github/branch-deploy@vX.X.X
  with:
    sticky_locks: true # <--- enables sticky deployment lock / hubot style deployment locks
    # ... other configuration

Enabling sticky deployment locks for .deploy and .noop commands:

- name: branch-deploy
  id: branch-deploy
  uses: github/branch-deploy@vX.X.X
  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