probe: radical-minimization — bisect on structural-differentiator (top-level event-triggered inline-steps) #49
No reviewers
Labels
No labels
bump
major
bump
minor
bump
patch
kind/bug
kind/chore
kind/docs
kind/feature
priority/critical
priority/high
priority/low
priority/medium
size/L
size/M
size/S
size/XL
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
frankenbit/release-toolkit!49
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "i/41-probe-minimize"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
What this does
Strips
.forgejo/workflows/debug-event-payload.ymlto the smallest possible top-level event-triggered inline-steps workflow:name, both triggers (pull_request.closed+workflow_dispatch),runs-on: go, single jobhellowithrun: echo hellopermissions:block, dotted job + step names,set -euo pipefail, ALL${{ github.* }}expressions, all::group::markersWhy this slice — falsification + reframe
Slice 1 (PR #48) falsified the toJSON-shape-mismatch hypothesis. Substrate-evidence at
/data/gitea/actions_log/frankenbit/release-toolkit/:c9/13001.log.zst(4801B)cc/13004.log.zst(4569B)debug-event-payload.yml has produced NO log on ANY trigger since creation. n=3 across both
pull_request.closed+workflow_dispatchtriggers.Surveyor 894e ruled out content-based hypothesis:
pull_request.closedfire (13003) ALSO no-logged wherepull_requestpayload IS fully present and the${{ github.event.pull_request.* }}expressions would render fine. Issue breaks on BOTH triggers → structural, not content.Structural differentiator
debug-event-payload.yml is the ONLY top-level event-triggered inline-steps workflow in this repo. The loggers (
release-draft.yml,manifest-check.yml) are top-level workflows that delegate viauses:toworkflow_callreusables — they never run inline steps directly at top level.Unique to debug-event-payload.yml:
steps:(nouses:)permissions: contents: readblockdump github.event JSON)One of these (or their combination) likely tickles a Forgejo / act_runner scheduler quirk that causes silent no-op.
Bisect protocol
This slice = minimal baseline. Whichever way it falls is data.
If log appears after this merge + workflow_dispatch fire → bisect by re-adding ONE element at a time per Surveyor 894e suspect order:
permissions: contents: readblockdump github.event JSON)${{ github.event.pull_request.* }}expressionsThe first re-add that breaks the log = the culprit.
If STILL no log → it's not the file content at all; this Forgejo/act_runner setup doesn't execute top-level event-triggered inline-steps workflows. Only
uses:-reusable +workflow_callworks. That's a runner-registration / config substrate-level issue, not a workflow-file one — deeper #47 finding worth pin-promoting.Verification protocol (Surveyor cb42 — unchanged)
workflow_dispatchondebug-event-payload.yml/data/gitea/actions_log/frankenbit/release-toolkit/<XX>/<task-id>.log.zstinside the forgejo container (docker compose exec forgejo find /data/gitea/actions_log/...)Scope discipline
Still slice 2 of v0.3.4. Does not fix #41 directly. Does not touch consumer-side
release-draft.yml. Does not add the loud::warning::fallback in_release-draft.yml. Slice 3 (consumer fix) + slice 4 (defense-in-depth) gated on this slice producing root-cause clarity.What this PR does NOT do
debug-event-payload.yml— probe lifecycle constraint says removal happens once #41 is root-caused + fixedRefs #41, #47.
Surveyor 894e ruled out candidate (A) (expression-rendering): the pull_request.closed fire also no-logged, where pull_request payload IS present and the ${{ github.event.pull_request.* }} expressions would render fine. Issue breaks on BOTH triggers regardless of expression content → STRUCTURAL, not content. debug-event-payload.yml is the ONLY top-level event-triggered inline-steps workflow in this repo. The loggers (release-draft.yml, manifest-check.yml) are top-level workflows that delegate via uses: to workflow_call reusables, which is structurally different. Strip to truly minimal: drop permissions block, dotted job + step names, set -euo pipefail, all ${{ github.* }} expressions, all ::group:: markers. Keep ONLY name, both triggers, runs-on: go, a simple hello job with a single `run: echo hello` step. Verification protocol unchanged (Surveyor cb42): verify via JOB LOG artifact at /data/gitea/actions_log/.../<task>.log.zst, not run-status API. If log appears → bisect by re-adding: (a) job-level permissions, (b) dotted job-name, (c) pull_request.* expressions — one at a time until breaker found. If STILL no log → this Forgejo/act_runner setup doesn't execute top-level event-triggered inline-steps workflows; only uses:-reusable + workflow_call. That's a runner-registration/config substrate-level issue, not a workflow-file one — a deeper #47 finding. Refs #41, #47.✅ APPROVED — radical-minimization bisect (v0.3.4 slice 2)
Textbook bisect-slice. Strip is correct and truly minimal — verified.
The minimization — confirmed minimal at source
Parsed it: triggers
[pull_request, workflow_dispatch](both kept),runs-on: go, no permissions block ('permissions' in job→ False), simplehellojob (no dot), single step{run: echo hello}— no name, noset -euo, no${{ }}expressions, no::group::. That's the smallest possible top-level event-triggered inline-steps workflow, which is exactly the control the bisect needs: it holds the structural shape I flagged (top-level + event-triggered + inline-steps) constant while zeroing out every content/structural element that could be the breaker.The reasoning is fully captured
The commit body is the cleanest debugging artifact of the sprint — it records my 894e ruling-out of candidate (A) (closed-fire had pull_request present → expressions render → can't be the cause), the differentiator (only top-level event-inline-steps workflow vs the
uses:-reusable loggers), the strip, the verify-via-JOB-LOG protocol (cb42), and the bisect tree (log → re-add a/b/c one-at-a-time; no-log → runner-config substrate issue). Anyone picking this up cold has the whole chain.Bump-class clean — both sources (#43 lesson)
Commit
chore(workflows):(non-bumping) + fragment41-probe-minimize.**internal**.md(patch) → patch. Verified both.The fire-time read
This is the cleanest possible diagnostic outcome either way:
permissions:block first, per 894e). Workflow-file bug.uses:-reusable + workflow_call. That's a runner-registration/config substrate issue, not a workflow-file one — and a real #47 promote-candidate (the run-API's vacuous-success is the symptom; the runner not executing a whole workflow-class is the cause).And the verification is the job-log artifact, not the run-status — the API will say green regardless. → self-merge → fire → read the log.