Cut release 0.1.0: freeze src/generated/0_1_0/ in lockstep with the version - #6
Conversation
…ersion One `cutRelease()` + `forge fmt` run: the rolling candidate is frozen into `src/generated/0_1_0/` and `LibMetaBoardReleased.releasedSuites()` is regenerated from the record that now holds it. `[external.package].version` was already `0.1.0` — this repo was created naming the version its first tag would cut — so the only field that moves is the snapshot, and `foundry.toml` drops the paragraph saying nothing is frozen yet, which this commit makes false. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
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 ignored due to path filters (1)
📒 Files selected for processing (2)
💤 Files with no reviewable changes (1)
Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review. Walkthrough
ChangesMetaBoard release metadata
Estimated code review effort: 2 (Simple) | ~10 minutes Merge Risk: ⚪ Minimal · up to This PR freezes the 0.1.0 generated snapshot and updates the released-suite index without introducing an actionable merge-blocking risk; it is merge-ready after normal checks and review. Suggested reviewers: 🚥 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 |
|
@coderabbitai review |
✅ Action performedReview finished.
|
Cuts release 0.1.0 on the two-field contract
rainix-static release-guardholds asol-v*tag to: the tagged commit must carry[external.package].version== the tag version AND the frozensrc/generated/<tag>/snapshot it names. The version field was already0.1.0(this repo was created naming the version its first tag would cut), so the only field that moves here is the snapshot, cut in onecutRelease()+forge fmtrun with the released-suites lib regenerated alongside.MetaBoardwas deployed before this PR — run 32523737176 (Manual sol artifacts,workflow_dispatchonmain) — so the attestation this freeze arms has its subject already on chain. No further broadcast is a prerequisite here.What changed
src/generated/0_1_0/MetaBoard.sol— the frozen snapshot, byte-identical to the rollingsrc/generated/candidate/MetaBoard.sol(both sha256a9ec5fc57f8f548e9427f3b8ab23763cc923c5bfdefb93f679455ccaa7c168db): sameCREATION_CODE, sameBYTECODE_HASH0xb7b74d879e97f272145d32ce18bd060f1e9f387696911376191ca10ecf24bed6, sameDEPLOYED_ADDRESS0x8fD50fF9Db9835ba1B61394752A26F53D721D2a1, same emptyDEPENDENCIES.src/lib/LibMetaBoardReleased.sol— regenerated in the samecutRelease()run, soreleasedSuites()goes from length 0 to the onemetaboard@0_1_0entry aliased from that frozen file. This is the commit that givesRainDeployVerifyChainits first subject; it is regenerated here rather than in a follow-up becausetestEveryFrozenSnapshotIsReleasedfails on either half landing without the other.foundry.toml— drops the paragraph saying nothing is frozen yet. This commit is the one that freezes it.Release-path gates, run locally against this commit
Not restated from the workflow — each was executed against
beb1eea:forge script ./script/Build.sol && forge fmt(the non-freezingrun(), which is what the release re-runs) leavesgit status --porcelainempty on this commit. Also verified empty on the base commit beforehand, so the freeze is the only thing this diff moves.rainix-static release-guard --version 0.1.0, at the release's pinnedRAINIX_SHAc4cf22d, reports:clean — foundry.toml version, src/generated/0_1_0/ present and newest, tree regenerates unchanged, frozen release matches src/generated/candidate/.MetaBoardDeployChainTest::testSuitesLiveOnEverySupportedNetworkagainst public archive endpoints for all seven supported networks.Per-network
eth_getCodeatlatestfor0x8fD50fF9Db9835ba1B61394752A26F53D721D2a1, read directly rather than through anything this repo asserts, thenkeccak256'd and compared to the frozenBYTECODE_HASH:0xb7b74d87…bed6OK0xb7b74d87…bed6OK0xb7b74d87…bed6OK0xb7b74d87…bed6OK0xb7b74d87…bed6OK0xb7b74d87…bed6OK0xb7b74d87…bed6OKAll seven match, so nothing blocks the tag on the chain side.
QA
MetaBoardDeployChainTest::testSuitesLiveOnEverySupportedNetwork— passed VACUOUSLY on basemain, wherereleasedSuites()was empty socheckDeployedOnSupportedNetworkstook itsderived.length == 0early return without touching a single RPC; this diff is what gives it a subject, and it now forks all seven networks and passes against the live chain (verified by running the suite on this branch with all seven*_RPC_URLbound to public archive endpoints).MetaBoardDeploySnapshotTest::testEveryFrozenSnapshotIsReleasedfails on base if a freeze lands without itsreleasedSuites()entry or the reverse — verified by construction, which is why the generated lib is regenerated in this same commit rather than after.testSnapshotMatchesSourcefails on any drift between the frozen/candidate bytes and what source compiles to.script/Build.solemits (a hand mutation of either is exactly what the gates below catch). The standing gates discriminate instead: a hand edit insidesrc/generated/0_1_0/fails the frozen-snapshots-append-only gate at PR time, a hand edit toLibMetaBoardReleased.solfails the release's own determinism re-run (git statusnon-empty), and drift between the freeze and source failsMetaBoardDeploySnapshotTest.eth_getCodeatlatestfor0x8fD50fF9…on all seven supported networks from public endpoints,keccak256'd and compared to the frozenBYTECODE_HASH(table above). The frozen bytes have a second independent oracle: sha256 equality withsrc/generated/candidate/, whichscript/Build.solderives from compiled source, not from this diff.0.1.0, re-verified by the guard), frozensrc/generated/0_1_0/snapshot, regenerated released-suites lib, and the tagsol-v0.1.0to follow on the merge commit. NOT covered and deliberately out of scope: the subgraph deployment record (Take the subgraph's deployment record and wire it to the deploy records #4, which stays open by ruling — the subgraph is not being stood up yet), and the on-chain broadcast, which already happened in run 32523737176 and is not part of the release workflow by design.🤖 Generated with Claude Code
Summary by CodeRabbit
New Features
Chores