Repository navigation
release: rain-deploy 0.1.15 - #269
Conversation
0.1.15 carries no source change over 0.1.14. Both records are byte-identical, so every pin a consumer reads is the same; what moves is the version and the `src/generated/0_1_15/` copy of the same frozen candidate. It exists because 0.1.14 cannot be published. `sol-v0.1.14` passed `release-guard` and then failed in the suite the publish job runs: `rpc.mainnet.chain.robinhood.com` answered 403 under 32 parallel forks and took 13 tests with it, 655 passing. rainix #406 drops that endpoint to last behind tenderly and publicnode, and #407 records the measured reason. A tag is the only release trigger and a published tag is not re-pushed, so the retry is a version, not a re-run. Measured here after the reorder, with robinhood bound to tenderly: 668 passed, 0 failed. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configuration
⛔ Files ignored due to path filters (2)
📒 Files selected for processing (3)
Included review availability: This review used your included allowance. Your plan provides up to 1 included review per hour; 0 remain after this review. WalkthroughThe external package version changes from 0.1.14 to 0.1.15. The AddressRegistry and MigrationRegistry released-suite lists each add a 0.1.15 entry. ChangesRelease 0.1.15
Priority: ➖ Normal Estimated code review effort: 2 (Simple) | ~8 minutes Change: Other Suggested reviewers: Merge Risk: ⚪ Minimal · up to The 0.1.15 release metadata is consistent with the repository’s frozen-release records. Available evidence does not establish that the reported RPC failures block this release. 🚥 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 |
The release commit for rain-deploy 0.1.15. It carries no source change over 0.1.14 — both frozen records are byte-identical, so every pin a consumer reads is the same.
Why a second version
sol-v0.1.14passedrelease-guardand then failed inside the suite the publish job runs:rpc.mainnet.chain.robinhood.comanswered 403 under 32 parallel forks, taking 13 tests with it while 655 passed (run). Nothing reached Soldeer.The endpoint is not broken for ordinary use — from one host the same hour it answered curl (including a 32-way concurrent burst, 32/32) and
cast chain-id. It fails only under the fork load a real suite produces, which is why no probe saw it coming. rainix #406 drops it to last behind tenderly and publicnode; #407 corrects the reason recorded next to it.A tag is the only release trigger and a published tag is not re-pushed, so the retry has to be a new version rather than a re-run.
QA
forge script script/Build.sol --sig 'cutRelease()'; the existing record tests (GeneratedSnapshotShape.t.sol,BuildRecordRoot.t.sol,BuildScript.t.sol,Build.t.sol) are what discriminate it.src/abstract/,src/lib/LibRainDeploySnapshot.solorscript/is in the diff.release-guardfor what the tagged commit must carry (version identity, record present inHEAD), and 0.1.14's own release commit for the diff shape, which this matches file-for-file.src/generated/0_1_15/frozen, released-suites libs at 7 entries, monotonicity satisfied, and the RPC cause fixed upstream rather than worked around in this repo. Verified:0_1_15/is byte-identical to0_1_14/and to the committedcandidate/, so the freeze introduced no drift. Deliberately not done — re-runningsol-v0.1.14(hook-blocked, and a tag is the trigger), and setting aRPC_URL_ROBINHOOD_FORKsecret for this repo alone (none is set at repo or org level; the fix belongs in the shared table).forge test668 passed / 0 failed with robinhood bound to tenderly; the same tree was 655/13 against the official endpoint, which is the failure reproduced locally.forge fmt --checkclean.🤖 Generated with Claude Code
Summary by CodeRabbit