ci: add rsk-contracts-test workflow and fix PATH-sensitive forge binary test - #40
ci: add rsk-contracts-test workflow and fix PATH-sensitive forge binary test#40fedejinich wants to merge 2 commits into
Conversation
…ry test Adds a Foundry-pinned (1.2.3, matching mise.toml and op-deployer/pkg/deployer/forge/version.json) CI job that runs forge build and forge test for packages/contracts-rootstock plus the op-deployer forge Go tests that rsk-test.yml deliberately excludes for lack of a Foundry-enabled runner. The path filters include the workflow file itself and op-deployer/pkg/deployer/forge/** so the PR adding it — and future changes to either — actually trigger it. TestStandardBinary_Downloads now sanitizes PATH, mirroring its sibling test, so a standard-version forge on PATH cannot short-circuit Ensure() before the download path under test is reached. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
There was a problem hiding this comment.
Pull request overview
Adds a Foundry-enabled GitHub Actions workflow for the RSK fork to run forge build/test for packages/contracts-rootstock and to execute the previously-excluded op-deployer/pkg/deployer/forge/... Go tests on a runner with forge installed, plus a small Go test tweak to make those tests deterministic when forge is present on PATH.
Changes:
- Add
.github/workflows/rsk-contracts-test.ymlto run contracts-rootstock Foundry builds/tests and the op-deployer forge Go test suite with Foundry pinned to v1.2.3. - Fix
TestStandardBinary_Downloadsto clearPATHsoStandardBin.Ensure()exercises the download path consistently in CI.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| op-deployer/pkg/deployer/forge/binary_test.go | Clears PATH in a download-focused test to avoid accidentally satisfying Ensure() via a forge already on PATH. |
| .github/workflows/rsk-contracts-test.yml | Introduces a CI workflow that installs a pinned Foundry version, initializes needed Solidity submodules, runs forge build/test, then runs the Go tests that require forge on PATH. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.
Suppressed comments (2)
.github/workflows/rsk-contracts-test.yml:51
- The job id
contracts-rootstockis shown in the Actions UI, but this job also runsgo test ./op-deployer/pkg/deployer/forge/.... Consider adding an explicit jobname:(or renaming the job id) so it’s clear the workflow covers both workloads when scanning CI results.
jobs:
contracts-rootstock:
runs-on: ubuntu-latest
op-deployer/pkg/deployer/forge/binary_test.go:56
- The new test comment hard-codes
v1.2.3, which can become stale ifStandardVersionis bumped later. Prefer wording that doesn’t embed a specific version (or refers to the pinnedStandardVersionconceptually).
// Clear out the PATH env var so the standard forge on PATH (v1.2.3 in CI)
// can't satisfy Ensure() before the download path under test is reached.
| paths: | ||
| - 'packages/contracts-rootstock/**' | ||
| - 'packages/contracts-bedrock/**' | ||
| - 'op-deployer/pkg/deployer/forge/**' | ||
| - '.github/workflows/rsk-contracts-test.yml' |
There was a problem hiding this comment.
Missing a few paths that also affect build correctness here: go.mod, go.sum, op-service/httputil/**, op-service/ioutil/** (the Go package under test imports these), and mise.toml (where the 1.2.3 pin this job asserts also lives). A change to any of these right now wouldn't retrigger this job. Same list is duplicated under push: below, needs the same fix there.
| on: | ||
| pull_request: | ||
| branches: [rsk/**] | ||
| paths: |
There was a problem hiding this comment.
A required check gated by paths: never runs on PRs outside those paths, so it stays stuck on Pending forever for them. rsk-test.yml has no path filters, probably why it's safe to require. Since this one's going into required status checks, drop the filters here too (or add a skip job reporting the same check name) before that happens.
| # forge.PathBinary() resolves and what StandardBin.Ensure() compares | ||
| # against StandardVersion ("v1.2.3") before falling back to a download. | ||
| - name: Test op-deployer forge package | ||
| run: go test -timeout 20m ./op-deployer/pkg/deployer/forge/... |
There was a problem hiding this comment.
This is the first CI run of TestStandardBinary_ForgeBins, which downloads six unauthenticated Foundry release tarballs from GitHub with no retry. New flake vector this job introduces, worth being aware of if it starts failing intermittently on network blips.
| # optimizer_runs = 5000, and the Go tests download six Foundry release | ||
| # tarballs (TestStandardBinary_ForgeBins). Expected wall time is ~8-15 min; | ||
| # 30 is a ceiling, not a target. | ||
| timeout-minutes: 30 |
There was a problem hiding this comment.
With go test -timeout 20m below (line 125), a hang in the Go tests hits this job's 30 min ceiling before its own 20m timeout fires, so you lose the goroutine dump that would show where it's stuck. Bumping this to ~45m (or dropping the go test timeout to ~15m) would let the more specific timeout fire first.
| # No --depth: the pinned commits are not all branch tips, and a shallow | ||
| # submodule fetch can fail to reach them. | ||
| - name: Check out contracts-bedrock submodules | ||
| run: git submodule update --init --recursive --jobs 4 packages/contracts-bedrock |
There was a problem hiding this comment.
nit: nothing here is cached beyond setup-go's Go module cache. Submodule clone, solc download, and the bedrock compile at optimizer_runs=5000 all happen from scratch every run. Not a correctness issue, just wall clock and repeated network calls.
| - 'op-deployer/pkg/deployer/forge/**' | ||
| - '.github/workflows/rsk-contracts-test.yml' | ||
|
|
||
| permissions: |
There was a problem hiding this comment.
nit: no concurrency: group, so superseded runs on rapid pushes keep burning minutes instead of getting cancelled. Same as the other rsk-* workflows, not specific to this PR.
| - name: Show forge version | ||
| run: | | ||
| forge --version | ||
| forge --version | grep -Eq '(^|[^0-9])1\.2\.3([^0-9]|$)' || { |
There was a problem hiding this comment.
nit: this greps the whole multi-line forge --version output, so a 1.2.3 inside a commit hash or build timestamp line would also match. Piping through head -1 first would be tighter, though practical risk is low.
|
|
||
| jobs: | ||
| contracts-rootstock: | ||
| runs-on: ubuntu-latest |
There was a problem hiding this comment.
nit: runs-on: ubuntu-latest isn't pinned to a specific image. Same as the other rsk-* workflows, so not a regression here.
Adds
.github/workflows/rsk-contracts-test.yml— the Foundry-enabled CI lane PAYROLLUP-80 left open — plus a one-line test fix required to make it green. Closes PAYROLLUP-90.What the workflow does
One job on
ubuntu-latest(SHA-pinned actions,permissions: contents: read,timeout-minutes: 30):persist-credentials: false) and scope-initializes the 11 Solidity submodules underpackages/contracts-bedrock/lib— deliberately notsubmodules: recursiveon checkout, which would also clone the unrelated repo-root Rust submodules (op-rbuilder,rollup-boost).foundry-rs/foundry-toolchain(pinned to the v1.9.0 commit SHA; v1.9.1 is 1 day old and the repo's Dependabot cooldown is 10 days).forge --versionis echoed and guarded — the job fails loudly if the pin didn't take. 1.2.3 is the version the repo already pins inmise.toml(lines 49–51) andop-deployer/pkg/deployer/forge/version.json.forge build+forge testinpackages/contracts-rootstock(19 tests).go test ./op-deployer/pkg/deployer/forge/...on the same runner — the packagersk-test.ymlintentionally excludes because it needs a realforgebinary.The test fix (
binary_test.go, +4 lines)TestStandardBinary_Downloadsnever sanitizedPATH, unlike its siblingTestStandardBinary_ForgeBins.StandardBin.Ensure()prefers a PATH forge whose version equalsStandardVersion(v1.2.3) before falling back to the download path the test exercises — so on any machine with forge exactly 1.2.3 on PATH (i.e. precisely what this workflow sets up), both subtests fail. Reproduced locally:FAILwithout the fix,okwith it. The fix is the samet.Setenv("PATH", "")pattern the sibling test already uses. Upstreamdevelophas the same latent bug; this is upstreamable as-is.Path filters — two deliberate choices
workflow_dispatchonly works once the file is on the default branch).op-deployer/pkg/deployer/forge/**, going beyond the ticket's literal "packages/contracts-**changes": this job is the only CI that runs that Go package's tests, so changes to the package must trigger it.Local verification (forge 1.2.3, darwin_arm64)
forge build: clean build in ~16 s;forge test: 19/19 passed (~0.5 s).go test ./op-deployer/pkg/deployer/forge/...: ok in ~19 s with forge 1.2.3 first on PATH (includingTestStandardBinary_ForgeBinsdownloading all six release tarballs).