fix(lr-d4413a): stop beta release job from clobbering main's version basis#347
Conversation
|
PEACHES — clean (0 nits) The PR correctly fixes the beta release workflow's silent no-op bug by (1) preventing the sync step from clobbering main's version basis and (2) adding a fail-loud check when a dispatched beta publishes nothing.
No blocking issues. |
|
BOBBIE security audit of PR #347 (fix/lr-d4413a-beta-release-no-op -> main). Scope: .github/workflows/release.yml only (workflow-file diff, in-scope per lr-e41b injection/runner-label/token surface). Review:
Scanners: gitleaks findings are pre-existing files outside this diff (worktree cert fixtures), not introduced by this PR — excluded per diff-scoping. semgrep p/github-actions: 0 findings on release.yml. osv-scanner: pre-existing package-lock.json CVEs unrelated to this diff (PR touches only the workflow file) — excluded per diff-scoping. No blocking or nit findings. scanners_run: gitleaks(no diff-scope hits), semgrep p/github-actions(0 findings), osv-scanner(pre-existing, out of diff scope) |
|
Merged via clagentic-loadout v0.1.0
|
What
Fixes the beta release workflow silently no-op'ing after a stable cut (lr-d4413a).
Two changes to
.github/workflows/release.yml,betajob only:origin/releaseintomain(--no-edit -X theirs) for tag reachability, but now explicitly restores main's ownCHANGELOG.md/package.json/package-lock.jsonfrom the pre-merge HEAD afterward instead of taking release's copies. Previously this step unconditionally rangit checkout origin/release -- CHANGELOG.md package.json package-lock.json, which force-copied release's STABLE version snapshot onto main whenever release was ahead (i.e. right after a stable cut). That reset main's version basis below the feature commits meant to drive the next beta, so semantic-release's commit-analyzer saw no releasable commits and exited success with nothing published — a green no-op.Run semantic-release (beta)now records whetherHEADmoved (semantic-release always commits+tags on a real publish); a following step fails withexit 1and a diagnostic message if it didn't. An operator-dispatchedtype=betawith zero output is an error the operator must see, not a silent green run — this only applies to theworkflow_dispatch-triggered beta job, no scheduled/passive trigger is affected.Why
Root cause (confirmed via lr-d4413a investigation, GH Actions run 29445794624): stable v1.7.0 was cut on
release(commitae58f95), then atype=betadispatch onmain(7 feature PRs #340-#346 landed since) ran step 5 before semantic-release, mergedreleaseintomain, and force-copiedrelease's stablepackage.json/CHANGELOG.mdontomain. semantic-release then computed the current version as 1.7.0 with the 7 feature commits sitting below that synced tag boundary — no release computed, all green, nothing published, and the operator'sinstall:local-testloop got poisoned onto stable 1.7.0.Trade-offs considered
npx semantic-releaseoutput — semantic-release doesn't expose a machine-readable no-op signal on stdout without additional plugin config, and a HEAD move is true for every successful publish (@semantic-release/gitalways commitspackage.json/CHANGELOG.md).promote/stablejobs untouched per scope — the stable job's own "sync stable version files back to main" step is the same operation but in the correct direction (release's clean stable version really should land on main after a real cut), so it was intentionally not touched.Testing
npm test: 978/982 pass, 4 pre-existing failures (lr-1f7econtext-window-warn suite) reproduced identically onmainbefore this change (verified viagit stash+ baseline re-run) — unrelated to this workflow-only diff, not introduced by it.Task: lr-d4413a