ci: pin Foundry to v1.5.1 to avoid nightly drift - #172
Open
amiecorso wants to merge 1 commit into
Open
Conversation
CI installed foundry 'nightly', which changes daily and quietly shifts remappings auto-resolution, evm_version clamping, and fmt rules -- the same class of drift that recently produced a non-canonical CREATE2 deploy address. Pin all three foundry-toolchain installs (forge-test, forge-coverage, certora verify) to v1.5.1, and document matching it locally via 'foundryup --install 1.5.1'. Verified v1.5.1 reproduces the canonical addresses exactly: implementation 0x00000110dCdEdC9581cb5eCB8467282f2926534d and factory 0xBA5ED110eFDBa3D005bfC882d75358ACBbB85842. Co-authored-by: OpenCode <opencode-noreply@coinbase.com>
Collaborator
🟡 Heimdall Review Status
|
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
2 participants
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.
Why
CI installs Foundry via
foundry-rs/foundry-toolchain@v1withversion: nightly, which advances daily. A floating toolchain quietly changes:evm_versionclamping (e.g.prague→shanghaion solc 0.8.23), both of which feed the contract metadata hash and therefore the deterministic CREATE2 deploy addressforge fmtrules, which drift between nightliesThis is the same class of non-determinism behind the recent non-canonical deploy-address fix (#171). For a repo whose purpose is redeploying the canonical CBSW v1.0.0 / v1.1.0 addresses on new chains, the toolchain should be frozen.
What
foundry-toolchaininstalls tov1.5.1:.github/workflows/test.yml(forge-test + forge-coverage jobs).github/workflows/certora.yml(verify job)foundryup --install 1.5.1.Verification
v1.5.1reproduces the canonical addresses exactly (forge clean && forge build,deployprofile):0x00000110dCdEdC9581cb5eCB8467282f2926534d✅0xBA5ED110eFDBa3D005bfC882d75358ACBbB85842✅Notes
solcstays pinned at0.8.23viafoundry.toml. This PR only freezes the forge/cast binary CI uses.forge fmtwhitespace andsoladysubmodule-fetch failures are separate pre-existing issues, see fix(remappings): pin ds-test to direct forge-std path so make deploy reproduces canonical addresses #171) — it prevents future toolchain drift.