Description

E2E setup was installing Anvil with the upstream foundryup script into the user’s Foundry directory and prepending that to PATH, while the repo pins Anvil through package.json and tests/seeder/anvil-manager.ts resolves node_modules/.bin/anvil when that file exists. In CI, the global install often “won” when the project-local binary was missing, so the chain did not always match local dev or the seeder’s resolved binary.

• ./.github/actions/setup-e2e-env: Replace the global Foundry/curl foundryup step with yarn install:foundryup so the version and checksums come from the same package.json foundryup config as the rest of the project. Remove the foundry-version input; bump the toolchain by editing that config, not a workflow input. After install, add $GITHUB_WORKSPACE/node_modules/.bin to GITHUB_PATH so bare anvil on the runner matches the project binary.
• build-android-e2e / build-ios-e2e: Restore the .metamask cache before the composite E2E setup action (so mm-foundryup can reuse download cache when available) and remove the redundant “Install Foundry if cache missed” step now covered by the action.
• run-e2e-workflow / update-e2e-fixtures: Restore .metamask before setup-e2e-env for the same cache behavior. No foundry-version was passed in callers; no consumer updates are required for removed inputs.

Changelog

CHANGELOG entry:

Related issues

Fixes: https://consensyssoftware.atlassian.net/browse/MMQA-1118

Manual testing steps

N/A

Screenshots/Recordings

N/A

Before

N/A

After

N/A

Pre-merge author checklist

• I've followed MetaMask Contributor Docs and MetaMask Mobile Coding Standards.
• I've completed the PR template to the best of my ability
• I've included tests if applicable
• I've documented my code using JSDoc format if applicable
• I've applied the right labels on the PR (see labeling guidelines). Not required for external contributors.

Performance checks (if applicable)

• I've tested on Android
  • Ideally on a mid-range device; emulator is acceptable
• I've tested with a power user scenario
  • Use these power-user SRPs to import wallets with many accounts and tokens
• I've instrumented key operations with Sentry traces for production performance metrics
  • See trace() for usage and addToken for an example

For performance guidelines and tooling, see the Performance Guide.

Pre-merge reviewer checklist

• I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed).
• I confirm that this PR addresses all acceptance criteria described in the ticket it closes and includes the necessary testing evidence such as recordings and or screenshots.