Twinned from https://github.com/cfsh/ninefold/issues/693 by tools/beads/import_github.py's reconcile pass.
Nothing is blocked — this only needs an answer if you have a preference. Rewritten 2026-08-07 because the first two versions buried the question under their own correction history. Sorry.
rebuild_f5.py builds f5/integration = main + every open PR branch, then force-pushes it. That takes ~40s, longer when the box is busy.
Just before it pushes, it re-checks the inputs it built from. If main moved, or if one of the branches it merged picked up a new commit, it refuses to publish and tells you to re-run. Nothing is lost — f5/integration is left alone and the next run picks everything up.
It exists because a build made on a stale main is missing whole merged PRs and looks fine: every branch in it still checks out as contained, so head-containment can't see the problem. That happened twice and is design 004 §1.4.
The re-check currently fires on two things. Should it fire on both, or just the first?
| trigger | what f5 would be missing if we published anyway |
|---|---|
| main moved | whole merged PRs — the real failure |
| a merged PR branch got a new commit | that one branch, one commit behind |
The second is much milder, and on a busy box it will fire more often — every refusal means f5 updates a bit later.
Both (shipped today). Strictest. Never publishes a build whose inputs moved at all.
Just main. One-line change. f5 publishes more often; occasionally one branch in it is a commit behind newest.
Leave it as shipped. I have no evidence yet that it is noisy — it has refused zero times in the rebuilds run so far today. If it starts crying wolf, narrowing to main-only is one line and the tests are already split by case, so I would rather find out than guess now.
Answer only if you'd rather it be looser from the start. Otherwise this closes itself the moment we have a week of real data.
None.
No comments.