Skip to content

Build1 publisher2 min readPublished

A git worktree per automation keeps the scheduled bots out of your working directory

A mutex kept his ten automations from colliding with each other but never from running git checkout in the directory where a deploy was in flight, so every bot now gets a disposable worktree of its own.

The Engineer · Build desk

Illustration accompanying A git worktree per automation keeps the scheduled bots out of your working directory

What happened

  • A scheduled automation spotted a new PR comment and ran git checkout in the author's working directory while a deploy was in flight, and the deploy finished on the wrong branch after his terminal froze for three seconds.
  • Every automation he had written began by cd-ing into ~/projects/my-repo and checking out a branch there, so two firing at once collided in the same folder.
  • All ten rebuilt workflows share a five-step skeleton that adds a worktree under $HOME/.automation/worktrees/$TICKET_ID at step 2 and removes it at step 5.
  • The review-comment bot polls every five minutes on PRs he authored, implements only the comments it judges unambiguous, flags the rest, and runs the build without committing.

Compiled by The EngineerSomething wrong?How this is made

Why it matters

  • exposure Anything reading files from disk during a run, a deploy included, is reachable by another process's checkout for as long as the working directory is shared.
  • capability Independent checkouts let several agents hold several branches at once, so concurrency stops being something a lock has to prevent.
  • cost Isolation is billed per run: 288 add-and-remove cycles a day for each five-minute workflow, each one into a directory that has to be made build-ready first.
  • decision Running the comment bot is a bet that your reviewers' comments split roughly 70/30 into clear and judgement calls, and that figure comes from one author's own pull requests.

A mutex was the first fix, and it worked on the problem it was built for: two automations could no longer run at the same time [6]. The question it asks is whether another automation is running, never whether a person is using the folder right now [6]. "Detection cannot reliably answer that question. Separation makes it unnecessary," he wrote [7].

`git worktree add ~/projects/my-repo-automation feature/pr-comment-fix` gives you a second directory attached to the same repository on its own branch, with no clone and no copy [8]. The command needs git 2.5 or newer [10]. He calls the add close to instant even on a large repo, and attributes that to the shared `.git` object store [8]. The saving is on objects. If the slow part of standing up your repo is materialising a large working tree, the add costs what that checkout costs, once per run.

Two of the ten workflows poll every five minutes [14][17]. That is 288 runs a day for each of them [18], and each run creates a worktree at step 2 and deletes it at step 5 [12]. Step 3 runs the build inside the fresh directory [14]. Anything the build needs that git is not tracking has to get there first, and the post does not say how the starter kit handles that; the workflow snippets are described as simplified sketches, with runnable versions later in the post [21].

The ticket workflow queries tickets updated in the last two hours, because a query for anything ever assigned to you re-triggers on old work forever [17]. At a five-minute cadence, one ticket sits inside that two-hour window for as many as 24 consecutive polls [19]. The comment workflow handles the same exposure with state, marking each comment processed once it has acted on it [20].

The figure he says surprised him is the split: roughly 70 percent of review comments resolve with no input from him, and the other 30 percent are the ones he actually needs to think about [16]. He wrote that sorting comments into those two piles was worth more than the fixes [16]. That split was measured on PRs he authored, which is also the only set the bot fires on [14]. For it to transfer, your reviewers have to write comments that partition the same way.

Step 5 is the one he says he never bends [22]. "Automation does the assembly. I keep the judgment," he wrote [13].

What to watch

  • Whether the starter kit's setup step gets dependencies and env files into each new worktree before step 3 runs the build.
  • Whether the 70/30 comment split holds on a repo with several reviewers instead of one author's own PRs.
  • Whether failed runs leave worktrees behind that the step 5 removal never cleans up.
Loading claim ledger
Loading source directory links
Loading share composer
Loading topic controls
Loading related stories