Two defects seen live on vm4006 when a merged branch was deleted from origin
while its last build still ran:
- The result prune removed the PENDING/RUNNING entries of branches gone from
origin, so the executing build vanished from UI and history and the queue
looked stuck. Prune now never touches a PENDING or RUNNING entry (worktrees
were already protected). The startup recovery closes out an orphaned PENDING
of a gone branch as INTERRUPTED, so the new immunity cannot leak entries.
- The apparent hang invited restart clicks, and each click stacked another
build of the same commit. startBuild now returns the already queued or
executing build of the same branch and commit instead of a duplicate;
cancel-requested builds do not block re-queueing, and re-running a finished
build stays possible.
Co-Authored-By: Claude <noreply@anthropic.com>
Build worktrees share the primary checkout's .git, so build tools can read
refs/heads there. Since the rewrite never moved those refs, they stayed frozen at
the last checkout: hs.hsadmin.ng's prQuickCheck compares master with
origin/master and therefore failed every build once origin moved on.
The sync runs after the enqueue decision on purpose — a local ref lagging behind
origin is exactly how the watcher recognizes new commits, so keeping the refs in
sync earlier (cron job, mirroring refspec, or this step moved up) would silence
the branch instead of building it.
Fast-forward only, as a compare-and-swap against the commit just read: diverged
or ahead branches stay untouched, and the checked-out branch is advanced with
merge --ff-only, which refuses to overwrite conflicting uncommitted changes.
Switched off with watcher.fastForwardLocalRefs: false.
Co-Authored-By: Claude <noreply@anthropic.com>
