Gate: a merge learnt seconds late moves the trunk; and a setting check-gates-merge so the merge check can stop gating (operator 2026-10-25 22:56)

Conversation 1 Commits 2 Files Changed 20

+328 -20

2 Commits

Author	SHA1	Message	Date
jschoubben	32ad59fc64	mesh-delivery-gate and gitea: a setting check-gates-merge; false asks a reviewed pull request's Approve and merges it without waiting for mesh/check mesh/delivery held for a person: merged without a passing check: only a person decides what follows Details mesh/check pass 32ad59fc6402 on 609013a2638f \| unit 2010 run, 2322 kept, 5 skipped \| integration 2032 run, 2341 kept, 9 skipped \| over bound: unit, in… The operator, 2026-10-25 22:56: "run the check locally only, but not as a gate, it loses us too much time". Tonight each merge ask waited 3-7 minutes for mesh/check, and every merge into main refused the next approved merge for a check judged on the trunk before (mesh-delivery#52). Both settings default to true, so nothing changes until the operator sets them. False: the gate makes a reviewed pull request ready and asks its Approve with no verdict, a trunk's move puts nothing out of date, a verdict is kept and shown, and a group still merges in one pass; the merge tool merges a head the Approve names whatever its mesh/check says. delivery_status and show say the mode.	2026-10-25 23:07:50 +01:00
jschoubben	93f655dac9	mesh-delivery-gate: a merge learnt from the open list seconds after it landed moves its trunk and source.main; delivery_status shows source.main mesh-delivery#51 merged 21:43:11 and the gate read the open list at 21:43:14, before the forge's merged event: taken as learnt late, it moved no trunk and its group's finish left it out of source.main, so the checker kept judging every mesh-delivery head on 73be3df. A late merge within replayLate of its landing is now taken as heard as it happened, and one a gate before this left is written at the catch-up of the start (never backwards).	2026-10-25 23:01:37 +01:00

Author

SHA1

Message

Date

jschoubben

32ad59fc64

mesh-delivery-gate and gitea: a setting check-gates-merge; false asks a reviewed pull request's Approve and merges it without waiting for mesh/check

mesh/delivery held for a person: merged without a passing check: only a person decides what follows

Details

mesh/check pass 32ad59fc6402 on 609013a2638f | unit 2010 run, 2322 kept, 5 skipped | integration 2032 run, 2341 kept, 9 skipped | over bound: unit, in…

The operator, 2026-10-25 22:56: "run the check locally only, but not as a gate, it loses us too much time". Tonight each
merge ask waited 3-7 minutes for mesh/check, and every merge into main refused the next approved merge for a check judged
on the trunk before (mesh-delivery#52). Both settings default to true, so nothing changes until the operator sets them.
False: the gate makes a reviewed pull request ready and asks its Approve with no verdict, a trunk's move puts nothing out
of date, a verdict is kept and shown, and a group still merges in one pass; the merge tool merges a head the Approve
names whatever its mesh/check says. delivery_status and show say the mode.

2026-10-25 23:07:50 +01:00

jschoubben

93f655dac9

mesh-delivery-gate: a merge learnt from the open list seconds after it landed moves its trunk and source.main; delivery_status shows source.main

mesh-delivery#51 merged 21:43:11 and the gate read the open list at 21:43:14, before the forge's merged event: taken as
learnt late, it moved no trunk and its group's finish left it out of source.main, so the checker kept judging every
mesh-delivery head on 73be3df. A late merge within replayLate of its landing is now taken as heard as it happened, and
one a gate before this left is written at the catch-up of the start (never backwards).

2026-10-25 23:01:37 +01:00

Gate: a merge learnt seconds late moves the trunk; and a setting check-gates-merge so the merge check can stop gating (operator 2026-10-25 22:56) #483