(motir-core) Verify on a REAL merge burst that no `Acceptance video` main baseline is evicted — the post-merge half of MOTIR-4095
Repo · motir-core. NO pull request — this card's deliverable is a MEASUREMENT recorded as a comment.
This is acceptance criterion 3 of MOTIR-4095, cut from that card and re-homed because it cannot be discharged there. MOTIR-4095 groups the Acceptance video lane's push: main runs per COMMIT so a merge burst stops evicting the queued baseline. A workflow's concurrency.group expression is read from the workflow file at the pushed commit, so the fix is only exercised by merges that land after MOTIR-4095's own pull request. MOTIR-4095 goes done on that merge; this card outlives it.
⚠️ Do not start this the moment it turns ready
blocked_by MOTIR-4095 discharges at MOTIR-4095's merge, which is the earliest moment this measurement is least possible — the burst has not happened yet. The earliest legal start is the first time main has taken ≥3 merges after MOTIR-4095's own merge commit. Check that first (step 1); if it has not happened, say so and leave the card open. A run that reports "no evictions" over a window containing no burst has measured nothing.
What to do
- Find MOTIR-4095's merge commit and confirm the burst exists —
mainhas taken at least three merges after it, with at least two of them less than the lane's run duration apart (~13 min), which is what puts a run in the pending state at all:gh api "repos/moooon-B-V/motir-core/commits?sha=main&per_page=40" \ --jq '.[] | [.sha[0:8], .commit.committer.date, (.commit.message | split("\n")[0])] | @tsv' - Read every
push: mainrun of the lane in that window, from the platform — not from a green check, not from the branch:gh api "repos/moooon-B-V/motir-core/actions/workflows/acceptance-video.yml/runs?branch=main&event=push&per_page=100" \ --jq '.workflow_runs[] | [.id, .head_sha[0:8], (.conclusion // .status), .created_at, .updated_at] | @tsv' - Per merge sha in the burst, assert two things: a run EXISTS for it, and that run has at least the
Does the lane hold a spec?job —gh api "repos/moooon-B-V/motir-core/actions/runs/<id>/jobs" --jq '[.total_count, ([.jobs[].name] | join(","))] | @tsv'total_count: 0is the eviction signature: a run cancelled while still pending never started a job. - Record the result as an
add_commenton THIS card AND on MOTIR-4095 — the run ids, the shas, the job counts, and the burst window. MOTIR-4095 is where the defect is described and where a reader will look for the proof.
Acceptance criteria
- A burst of ≥3 back-to-back merges to
main, all after MOTIR-4095's merge commit, is identified by sha and timestamp — or, if none has occurred yet, the card is left OPEN with that stated, and nothing is reported as verified. - For every merge sha in that burst, an
Acceptance videopushrun exists, read back from/actions/workflows/acceptance-video.yml/runs. - No run in the window is
cancelledwithtotal_count: 0jobs — the eviction signature. Any that is, is reported as the fix NOT holding, with its id. - Every run in the window carries at least the
Does the lane hold a spec?job. - The run ids, shas, job counts and burst window are recorded in an
add_commenton this card and on MOTIR-4095, with the commands that produced them.
Context refs
.github/workflows/acceptance-video.yml— theconcurrency:block MOTIR-4095 changed, and its header, which carries the pre-fix measurement.- MOTIR-4095 — the defect, the mechanism, and the pre-fix numbers this is measured against.
- ⚠️ MOTIR-4096 renames this lane and moves the workflow file. If it has landed first, the workflow path and the run's
namewill have changed — read the current file rather than assumingacceptance-video.yml.