Drop snapshot-generate-cmd: rainix owns the release freeze - #9
Drop snapshot-generate-cmd: rainix owns the release freeze#9thedavidmeister wants to merge 1 commit into
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
💤 Files with no reviewable changes (1)
WalkthroughThe tag-based package release workflow no longer runs ChangesPackage Release Workflow
Estimated code review effort: 1 (Trivial) | ~2 minutes Mergeability Score: 🔵 Low · up to This change is mergeable with explicit owner awareness: it must land after the reusable workflow removes the required input, otherwise tagged releases will fail before any release steps run. Possibly related issues
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
HELD — do not merge. Sequenced behind rainlanguage/rainix#302, which is itself held pending rainlanguage/rainix#304 (pointer generation belongs in This PR is NOT a no-op in the meantime: |
Drops
snapshot-generate-cmdfrom therainix-tag-releasecall. The freeze itused to name is now
rainix-static cut-releaseinside the reusable, which ownsthe regenerate ->
forge fmt-> freeze order rather than taking it as a shellstring (rainlanguage/rainix#301, implemented in rainlanguage/rainix#302).
This repo generates its pins with
forge script ./script/BuildPointers.sol,which is the reusable's default, so nothing replaces the removed line — the
with:block issoldeer-packagealone.Merge AFTER rainlanguage/rainix#302, not before
This is not a no-op today, and merging it first breaks the release path. On
rainlanguage/rainix@mainright nowsnapshot-generate-cmdisrequired: true. A caller that omits a required input fails atworkflow_callstartup ("Input is required, but not provided while calling"), so between this
merging and #302 merging, a
sol-v*tag here would fail immediately.The reverse order is safe: #302 deletes the input, and until this lands the call
passes an input the reusable no longer declares, which also fails at startup —
so the two are a coordinated set either way. #302 first is the better order
because the dependency then runs from a finished, reviewed PR to a one-line
follow-up that merges in seconds, rather than from a merged one-liner to a large
PR that might still be sent back for changes.
Neither failure can corrupt a release: both are input-validation errors raised
before any step runs, so nothing is generated, published or committed. The only
real precaution is not to push a
sol-v*tag between the two merges.Also required before this repo can release again
Separate from this PR:
mainhas nosrc/generated/candidate/— this repo'sscript/BuildPointers.solstill writessrc/generated/<version>/straight fromfoundry.toml.cut-releaserefuses whencandidate/is missing, so releaseshere also need #5 (the rolling-candidate migration) merged. #5 additionally
carries its own
snapshot-generate-cmd: bash script/cut-release.shline and itsscript/cut-release.sh; both should go when it lands, whichever of the two PRsis second.
QA
— GitHub validates
with:against the reusable's declared inputs at runstartup, so the only oracle is the reusable's own
on: workflow_call: inputs:block. Checked directly:
pointers-generate-cmd(optional, defaults to thisrepo's exact generate command) and no
snapshot-generate-cmdonrainix owns the deploy-repo release freeze: rainix-static cut-release rainix#302's branch;
soldeer-packageandtag-prefixunchangedand still declared. The remaining
with:key and everysecrets:entry werematched one by one against that block.
no executable logic to mutate. The failure modes were instead enumerated from
GitHub's validation semantics and stated above: input present but undeclared
(fails at startup), input absent but required (fails at startup), input absent
and optional-or-undeclared (correct). The merge order follows from which of
those the window lands in.
rainlanguage/rainix#302'srainix-tag-release.yamlread directly forthe post-merge input set, and
rainlanguage/rainix@main's read for thepre-merge one — the two differ on exactly this input, which is what makes the
ordering load-bearing. This repo's
script/BuildPointers.solread to confirmthe removed command equals the reusable's default.
Covered: the line is gone, nothing replaces it because the default already
matches, the comment block above the call makes no claim about the removed
input, and the ordering constraint the deletion creates is stated rather than
left for a release to discover.
🤖 Generated with Claude Code
Summary by CodeRabbit