Implement verification of reproducible builds and run differential E2E tests#468
Implement verification of reproducible builds and run differential E2E tests#468
Conversation
Prior to adding cache to this workflow, the build steps always ran,
which invoked the following: "make install-wasm" > "make install-npm" >
installed the solc npm package defined in "js/emscripten/package.json".
Thus, the explicitly downloaded soljson.js was never used since npm
module resolution first looks for an npm package when required with
"require('solc/soljson')" as before. With cache now added and on cache
hits, the build step no longer runs and just performs the sanity check,
which now detects this unintended behavior and fails since there is no
solc npm package. This commit updates it to look for the local file.
This allows using the same script for all builds including Wasm, and to make it more readable, maintainable, testable, and more easily allow for parallel compilations with Node async APIs.
The LLVM patch includes a possible fix for a bug causing different operand ordering when targeting the Microsoft ABI (producing different RISC-V and PVM bytecode for our Windows vs macOS/linux builds)
Includes building LLVM for Windows using clang-cl, and applies LLVM patches for deterministic operand order and correct peephole optimization for large integers for minsize (thus, the custom stripping of minsize has been removed). The patches are applied as part of llvm-builder, instead of in the workflow step as previously tested.
There was a problem hiding this comment.
This was the expectations file (expected test execution failures) generated by retester in this run.
Reason for the test execution failure of fixtures/solidity/simple/algorithm/cryptography/caesar_cypher.sol::2::Y M0 S-:
"Failed to execute all of the steps on the driver: Failure on step 0: Function call step Failed: Failed to handle function call assertions: Transaction status assertion failed - Expected true but got false. Revert reason: Some("ContractTrapped")"
| # TODO: Which Polkadot SDK commit do we want to use? | ||
| # The below one is as of March. 25, 2026. | ||
| POLKADOT_SDK_REF: "9d8a2fefd2414591c4a243460f3ffc5195a71deb" |
There was a problem hiding this comment.
This is a commit from Polkadot SDK main. Is there a particular tag we should use instead?
There was a problem hiding this comment.
Should this be aligned to what we have in Cargo.toml ? I.e. use the one that corresponds to 2507.4.0 ?
also, @xermicus, don't we need to also update this dependency ?
There was a problem hiding this comment.
Yes we test against the exact same time everywhere
elle-j
changed the title
xermicus
left a comment
xermicus
left a comment
There was a problem hiding this comment.
Running differential tests needs build caches for revive dev node and rpc binaries since (--profile production builds take long time to build)
| # TODO: Which Polkadot SDK commit do we want to use? | ||
| # The below one is as of March. 25, 2026. | ||
| POLKADOT_SDK_REF: "9d8a2fefd2414591c4a243460f3ffc5195a71deb" |
There was a problem hiding this comment.
Yes we test against the exact same time everywhere
3 participants
Description
This adds verification for reproducible builds (via revive-differential-tests testing framework) by:
0,3,zfor each contractThis PR also runs the differential E2E tests (via
retester) with the resolc linux musl build.All of the above only runs if our
testworkflow succeeds.Related
This PR initially implemented the above in this repo but has now been implemented into the separate testing framework instead. The most relevant PRs implemented alongside this PR as prerequisites are:
revive-differential-tests:modeand allow setting solc optimizer enabledcompilecontext/subcommand for standalone compilation mode--modeCLI argument forcompileexport-hashesandcompare-hashessubcommands for report processorcfg(unix)to fix Windows builds--compilecommandrevive:minsizellvm-project:SelectionDAGtype legalization produces different operand ordering fori256multiply across platformssolidity:Notes
Failed compilations
Since resolc-compiler-tests currently includes contracts that are expected to fail resolc compilation (e.g. due to unsupported instructions, contracts that are expected to work with solc for evm/revm), the compilation workflow job is not expected to fail if compilation fails for a contract.
Instead, if a contract compiles with one build but not with another, a hash will be missing and will thereby generate a mismatch when comparing all hashes, failing at the verification step.
Resolved Issues
Closes #175