fix(ci): skip CI on chore(release): commits to avoid tag-push race#80
Merged
Conversation
theogravity
added a commit
that referenced
this pull request
May 3, 2026
monorel's chore(release): commit (#79) wrote the wrong full-zip hash for go.loglayer.dev/v2@v2.1.0 into transports/cli/go.sum, transports/console/go.sum, and transports/pretty/go.sum: recorded: h1:jtVUg225o0K/7TCW5ob9OzjQLeRZxlNEIj8XbZOFjmY= actual: h1:8/fq8Z1NNLtjfKgaPn6S0Hy7zWPnkjn9Gj3YgEDFk4w= Direct fetch of the v2.1.0 tag from GitHub (the canonical bytes) gives the second hash. The first one is a hash of some pre-publish snapshot that monorel never resolved against the actual chore(release) commit. The mismatch breaks every fresh-cache install of v2.1.0 with "SECURITY ERROR: this download does NOT match an earlier download recorded in go.sum." Surfaced by CI on PR #80 (https://github.com/loglayer/loglayer-go/actions/runs/25272682675/job/74097592843). Recovery: strip the wrong h1: line from each affected go.sum and let `GOPROXY=direct GOSUMDB=off go mod tidy` repopulate the entry from the actual published bytes. The /go.mod sub-hash was correct in all three files; only the full-zip hash is wrong, so this is a one-line-per-file fix. Filed upstream as the latest comment on disaresta-org/monorel#54. Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The chore(release): merge commit updates every released module's
go.mod to require a new go.loglayer.dev version (e.g. v2.1.0). The
matching tag is created concurrently by release.yml on the same push.
ci.yml's `Verify modules tidy` step races with that tag push and
loses, producing a phantom CI failure on every release:
go: go.loglayer.dev/transports/cli/v2 imports
go.loglayer.dev/v2: reading go.loglayer.dev/go.mod at revision
v2.1.0: unknown revision v2.1.0
Meanwhile release.yml on the same commit succeeds and the tags get
pushed. The CI red-mark is misleading: the project is fine, it's just
a workflow-ordering bug.
Mirror the skip pattern release-pr.yml already uses: when the head
commit subject starts with chore(release): on a push to main, skip
the whole CI matrix. Pull-request runs are unaffected (the if-clause
keeps PR triggers always-on).
Filed upstream as disaresta-org/monorel#54
(comment on the existing thread); the recipe should be in monorel's
docs so other adopters don't hit the same flake.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
theogravity
force-pushed
the
fix/skip-ci-on-release-commits
branch
from
751be52 to
0aa15aa
Compare
2 tasks
theogravity
added a commit
that referenced
this pull request
May 3, 2026
monorel v0.14.0 (disaresta-org/monorel#57) ships the cacheseed fixpoint fix for issue #54, plus a built-in `primeModuleCache` step that populates the module cache for third-party deps before offline tidy runs. With those fixes upstream, this repo's local workarounds are redundant: - Bump the action pin from v0.11.0 to v0.14.0 in release-pr.yml and release.yml so the cacheseed wrong-h1: bug is fixed for our next release. Without this bump, the next chore(release) commit would ship broken go.sum entries for v2.x.y like v2.1.0 did. - Remove the "Prime module cache for monorel tidy" step from both workflows. monorel itself now does this internally per affected sub-module, filtering managed siblings out so the offline tidy that follows can resolve every transitive dep without needing the consumer to pre-warm the cache. Kept: - `actions/setup-go@v5` with go-version: '1.25' and cache: true. monorel still runs offline tidy with GOTOOLCHAIN=local, so the runner's Go must already match every sub-module's `go` directive. monorel v0.14.0 documents this requirement explicitly in the ci/github action README and in docs/src/workflows.md. - The `if: ... !startsWith(...) 'chore(release):'` filter on ci.yml jobs (added in PR #80). monorel doesn't auto-skip consumer CI workflows; the filter is the consumer's responsibility, and the pattern is now documented upstream. Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
3 tasks
theogravity
added a commit
that referenced
this pull request
May 4, 2026
monorel v1.0.0 ships `monorel auto`, a single command that detects whether HEAD is a release-PR merge and dispatches to either the post-merge release pipeline (tag, push, publish) or the pre-merge maintenance pipeline (apply changesets onto a staging branch, force-push, upsert the always-open release PR). The action wrapper no longer takes a `command` input; one workflow with one step does both jobs. Changes: - **Delete `release-pr.yml`.** Its job (upsert the release PR) is now done by `monorel auto` on every non-release push. - **Rewrite `release.yml`** as the single consolidated workflow. Single `monorel` job runs the v1.0.0 action on every push to `main` and lets the action route. The `deploy-docs` job (called via `workflow_call` from `docs.yml`) gates on `chore(release):` so docs deploy only on the release-PR merge, not on every feature merge. - **Bump action pin** from `v0.14.0` to `v1.0.0`. - **Update AGENTS.md** to describe the new single-workflow model in the CI / Release Workflows section. Kept: - `actions/setup-go@v5` with `go-version: '1.25'` and `cache: true`. monorel still runs offline tidy with `GOTOOLCHAIN=local`, so the runner's Go must satisfy every sub-module's `go` directive. - The `if: ... !startsWith(..., 'chore(release):')` skip filter on `ci.yml` jobs (PR #80). The race the filter prevents (CI tidy vs release tag-push) still applies under the consolidated workflow. - `workflow_dispatch` as a manual escape hatch. Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Third in a sequence of release-pipeline fixes (after #77 and #78). The
chore(release):merge commit updates each released module'sgo.modto require a newgo.loglayer.devversion (e.g.v2.1.0). The matching tag is created concurrently byrelease.ymlon the same push.ci.yml'sVerify modules tidystep races with the tag push and loses, producing a phantom CI failure on every release:Repro: https://github.com/loglayer/loglayer-go/actions/runs/25272543601/job/74097232242
Meanwhile
release.ymlon the same commit succeeds and the tags get pushed. The CI red-mark is misleading: the project is fine, it's just a workflow-ordering issue.Fix
Mirror the skip pattern
release-pr.ymlalready uses: when the head commit subject starts withchore(release):on a push tomain, skip the whole CI matrix. Pull-request runs are unaffected — the if-clause keeps PR triggers always-on.Applied to all three top-level jobs (
test,staticcheck,govulncheck) since each runsgo mod tidyindirectly viascripts/foreach-module.sh.Upstream
Filed as a follow-up comment on disaresta-org/monorel#54 — the recipe should be in monorel's CI docs so other adopters don't hit the same flake on every release.
Test plan
chore(release):subject triggers a clean CI run.ci.ymltriggers but the test/staticcheck/govulncheck jobs all skip cleanly (no phantom red mark).🤖 Generated with Claude Code