chore(ci): adopt monorel v0.14.0 and drop cache-priming workaround#82
Merged
Conversation
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>
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
Adopts monorel v0.14.0, which ships the fixes for issue #54 — the cacheseed wrong-h1: bug that broke our v2.1.0 release plus the cache-priming gap that initially blocked our
release-prworkflow.Changes
disaresta-org/monorel/ci/githubfrom@v0.11.0to@v0.14.0in bothrelease-pr.ymlandrelease.yml. Without this bump, the nextchore(release):commit would ship brokengo.sumentries (the same class of bug that caused the v2.1.0 SECURITY ERROR mismatch).Kept
actions/setup-go@v5withgo-version: '1.25'andcache: true. monorel still runs offline tidy withGOTOOLCHAIN=local(intentionally, for determinism), so the runner's Go must match every sub-module'sgodirective. v0.14.0's docs cover this requirement in ci/github/README.md and docs/src/workflows.md.if: ... !startsWith(..., 'chore(release):')skip filter onci.ymljobs (PR fix(ci): skip CI on chore(release): commits to avoid tag-push race #80). monorel doesn't auto-skip consumer CI workflows; the filter is the consumer's responsibility, and the pattern is now documented upstream.Test plan
release-prand the workflow completes successfully (release PR opens / updates).releaseworkflow runs the publish pipeline cleanly. The released sub-modules'go.sumentries record correcth1:hashes (verified by a downstreamgo getagainst the published versions).🤖 Generated with Claude Code