Configure Deployment Locking
Prevent multiple workflows from running on the same deployment at the same time with deployment locking in Atmos Pro.
When working in a team, it's common for multiple pull requests to trigger workflows targeting the same deployment. But which one should run first? What happens if they overlap?
Deployment locking helps you avoid conflicts by making sure only one workflow can run on a given stack at a time.
How it works
To prevent conflicting changes, you can lock a deployment before running a workflow. This tells Atmos Pro to block any other workflows from being dispatched to the same stack until the lock is released or expires.
The easiest way to lock a stack is to use the Atmos CLI. The Atmos CLI supports locking a stack by running the
following command:
atmos pro lock <key> --ttl <ttl> --message <message>key- The key of the stack to lock.
ttl- The time to live for the lock in milliseconds.
message- A message to display to anyone trying to lock an already locked stack.
When a deployment is complete, you can unlock it to allow new workflows to be dispatched. If needed, you can also use this command to forcefully unlock a deployment before the TTL expires.
The Atmos CLI is also the easiest way to unlock a stack that has been previously locked. The Atmos CLI supports unlocking a stack by running the
following command:
atmos pro unlock <key>key- The key of the stack to unlock.