Merging the v1.6.0 stack (!159–!164) queued eighteen jobs on main, builds 247–264, for six commits that had each just passed build, test and vuln on their branch (builds 229–246). A fast-forward lands the exact commit that was tested; nothing about it changed.
QueueBranchBuilds in internal/control queues every job for the new tip on any ref update, without asking whether that commit already has a build for that job. Jobs have no branch filter (ci.Job has Schedule and Tags only), so a job's result is a fact about the commit: GITBAY_REF differs, the steps and the tree do not.
Proposed: in QueueBranchBuilds, skip a job when the repository already holds a success build for the same (sha, job), whatever ref it ran on. The commit statuses from the earlier run are already on that sha, which is why require-checks was satisfied at merge time; the merged ref needs nothing more. A build that failed or was abandoned re-queues as now, so a re-merge after a fix is not blocked by an old failure. Nothing changes for webhooks: the push event for the merge still fires.
Cost of the current behaviour on this instance: about thirty minutes of the single runner per six-layer stack, and every future stack merge doubles its own CI.
Ref #65
closed by commit b1f7d169de by cmc: ci: a commit that already passed a job is not built again on landing
2026-09-02 03:42 UTC