fix(ci): assert the built version instead of pinning it to a fixture hash - #121
fix(ci): assert the built version instead of pinning it to a fixture hash#1210xdevcollins wants to merge 1 commit into
Conversation
…hash The SDK 27 compatibility gate has been red on testnet since 30 July. With VERIFY_SDK27_BUILD=1 it asserted that a freshly built boundless_events.wasm hashes to the pinned events-1.5.0-sdk27.wasm fixture. contractmeta! is embedded in the wasm, so that assertion stopped being satisfiable the moment the runtime version moved to 1.6.0, and would break again on every bump after. Re-pinning the hash would only defer it to the next release. What the pin was really guarding is that a shipped artifact declares the version its source claims, and contractmeta! and INITIAL_VERSION are independent declarations that have drifted before: fixtures/events-1.3.0-sdk23.wasm reports contractmeta 1.2.0 against a 1.3.0 runtime, which the manifest records as a known defect. The gate now compares the built wasm's contractmeta against INITIAL_VERSION for both contracts, which catches that class and survives version bumps. Verified by reverting events contractmeta to 1.5.0 against a 1.6.0 source: the gate fails with both values named. Fixture integrity, snapshot provenance and the compatibility suite itself are unchanged, and the fixture hashes stay pinned byte-for-byte.
Plan expiredYour subscription has expired. Please renew your subscription to continue using CI/CD integration and other features. |
|
Warning Review limit reached
Next review available in: 42 minutes Limit details: You’ve used all 1 included review currently available under your plan. You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
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 |
1 participant
The
buildworkflow has been red ontestnetsince 30 July. This unblocks it.What was wrong
With
VERIFY_SDK27_BUILD=1,scripts/test-sdk27-compat.shasserted that a freshly builtboundless_events.wasmhashes to the pinnedevents-1.5.0-sdk27.wasmfixture:contractmeta!(key = "version", …)is embedded in the wasm, so that assertion stopped being satisfiable the moment the runtime version moved to 1.6.0 in #105. Reproducible ontestnetatec2ae0cwith nothing else applied.verify-buildtestnetb12a976bump to 1.6.0testnetec2ae0cgate sdk 27 storage compatibility (#102)testneta7539bfsql modWhy not just re-pin the hash
It would go green until the next version bump and then fail identically. The fixture is a historical artifact — it is the "new" side of the SDK 23 → SDK 27 storage tests — so by design it drifts from HEAD as soon as HEAD moves on. Pinning the current build to it couples "is this build sound" to "is the version still 1.5.0".
What it asserts now
The property the pin was really guarding: a shipped artifact declares the version its source claims.
contractmeta!andINITIAL_VERSIONare independent declarations, and they have drifted before —fixtures/events-1.3.0-sdk23.wasmreports contractmeta1.2.0against a1.3.0runtime, which the manifest already records as a known defect. That is exactly the bug class this now catches, and it survives version bumps.Verified negatively rather than assumed. Reverting events
contractmetato1.5.0against a1.6.0source:Unchanged
Fixture hashes stay pinned byte-for-byte, snapshot provenance checks are untouched, and the compatibility suite itself is not modified. The only other change is a
noteon theevents-1.5.0-sdk27.wasmmanifest entry recording that it is historical and not expected to match a current build, so the next person does not re-pin it.Verification
Every step the
buildworkflow runs, locally on this branch with the required toolchain (rustc 1.93.0, Stellar CLI 27.0.0):VERIFY_SDK27_BUILD=1 ./scripts/test-sdk27-compat.sh— passes, including the 3 compatibility testsstellar contract build --locked— green, both wasms under the 64 KB ceilingcargo test— 225 events, 66 profile, 3 compatibilitycargo fmt --check— clean./scripts/test-mainnet-upgrade-guards.sh— passesbash -nondeploy_mainnet.shandscripts/capture-mainnet-compat-snapshot.shNote
#120 sits behind this. It carries the same red for the same pre-existing reason, and will go green once this merges and it rebases.