locktrigger

Overview ¶

Locktrigger “locks” a given build trigger, making sure that the currently running build is the only trigger running.

Usage:

locktrigger -project=$PROJECT_ID -build=$BUILD_ID

The $PROJECT_ID and $BUILD_ID are typically written literally in cloudbuild.yaml and then substituted by Cloud Build.

When a project uses “continuous deployment powered by Cloud Build”, the deployment is a little bit too continuous: when multiple commits land in a short time window, Cloud Build will run all the triggered build jobs in parallel. If each job does “gcloud app deploy”, there is no guarantee which will win: perhaps an older commit will complete last, resulting in the newest commit not actually being the final deployed version of the site. This should probably be fixed in “continuous deployment powered by Cloud Build”, but until then, locktrigger works around the problem.

All triggered builds must run locktrigger to guarantee mutual exclusion. When there is contention—that is, when multiple builds are running and they all run locktrigger—the build corresponding to the newest commit is permitted to continue running, and older builds are canceled.

When locktrigger exits successfully, then, at that moment, the current build is (or recently was) the only running build for its trigger. Of course, another build may start immediately after locktrigger exits. As long as that build also runs locktrigger, then either it will cancel itself (if it is older than we are), or it will cancel us before proceeding (if we are older than it is).