Description

Problem: Foundry download failures account for 16% (~10 runs) of the 64 Setup Environment CI failures on main over 30 days (Mar 16 – Apr 16, 2026). The failure modes include curl: (35) Recv failure: Connection reset by peer, corrupt tar archives, and malformed URLs. The current implementation has zero retry logic — a single curl or foundryup failure kills the entire step.

See INFRA-3580 for the full root cause analysis.

Solution:

Wrap the Foundry installation step in nick-fields/retry (3 attempts, 30s wait, 3min timeout per attempt), matching the existing repo pattern already used for Corepack, Yarn, and CocoaPods in the same file.

Key details:

• set -euo pipefail at the top of the command block to ensure failures propagate correctly (learned from bugbot review on PR #29236)
• on_retry_command cleans up partial/corrupt Foundry downloads (rm -rf $FOUNDRY_DIR) before each retry — addresses the "corrupt tar" failure mode
• timeout_minutes: 3 per attempt — Foundry download + install typically takes seconds
• GITHUB_PATH modification (echo "$FOUNDRY_BIN" >> "$GITHUB_PATH") works correctly inside nick-fields/retry since it's a file-based mechanism
• Replaced env: FOUNDRY_VERSION with inline ${{ inputs.foundry-version }} expression since uses: steps in composite actions resolve inputs at parse time

Changelog

CHANGELOG entry: null

Related issues

Fixes: INFRA-3580 (partial — addresses Foundry download failure sub-cause)

Manual testing steps

Feature: CI resilience for Foundry installation

  Scenario: Foundry install completes successfully with retry logic
    Given a PR triggers E2E tests on CI

    When the setup-e2e-env composite action runs
    Then the "Install Foundry" step uses nick-fields/retry
    And transient curl/foundryup failures are retried up to 3 times with 30s wait
    And partial downloads are cleaned up before each retry

  Scenario: Foundry binaries are available to subsequent steps
    Given the "Install Foundry" step succeeds via nick-fields/retry

    When subsequent steps reference forge or cast
    Then the binaries are found on PATH via GITHUB_PATH

Screenshots/Recordings

N/A — CI workflow changes only, no UI impact.

Before

N/A

After

N/A

Pre-merge author checklist

• I've followed MetaMask Contributor Docs and MetaMask Mobile Coding Standards. (N/A — CI workflow YAML only, no application code changes)
• I've completed the PR template to the best of my ability
• I've included tests if applicable (N/A — CI workflow configuration, validated by CI run on this PR)
• I've documented my code using JSDoc format if applicable (N/A — CI workflow YAML, no code)
• I've applied the right labels on the PR (see labeling guidelines). Not required for external contributors.

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.