Locking and staleness

plywood switches on chant’s target locks. A pull request takes its locks at its first preview and lets go when it merges or closes. Another pull request that needs one of them waits, or is refused at once from a comment. An update also holds the same keys while it runs, and lets go when it ends.

Setting	Lock key
locks.grain: resource (the default on plunge)	each URN the preview creates, updates, replaces or deletes
locks.grain: stack (the default on stock Pulumi)	the whole stack

On plunge, two pull requests that change different resources of one stack each get their preview and approval, and each can merge and update. A stack whose preview has resources that appear only during the update locks the whole stack for that update. On stock Pulumi plywood config check refuses locks.grain: resource, since the backend’s stack lock orders its updates.

Stock Pulumi

A stock backend holds one checkpoint per stack, and its stack lock orders updates. The second of two updates to one stack starts when the first ends, and previews again before it runs. A killed update leaves its lock for pulumi cancel, or the lock file on a self-managed backend.

With plunge

plunge is the Pulumi fork from the team behind plywood. It takes no stack lock: each resource is a record, and every write is conditional.

	Stock	plunge
Two updates to different resources of one stack	one after the other	side by side
A record moved after review	the fresh preview no longer matches, and the wave is refused	the saved plan refuses with exit 40
A merged wave plans something its pull request did not preview	the wave is refused with exit 4 when preview: true is set in plywood.yml; off by default	the same
A killed update	its stack lock stays held	nothing to release