Switch CI Docker image from Miniconda to Miniforge

[Copilot]

Summary

CI Docker image builds fail due to Anaconda package repository rate limits (Your usage of the Anaconda package repository exceeds our rate limits).

Switch from Miniconda to Miniforge, which uses conda-forge as its default channel and avoids Anaconda's default repository entirely. Miniforge is otherwise fully compatible.

• .ci/docker/common/install_conda.sh: Download from github.com/conda-forge/miniforge/releases instead of repo.anaconda.com/miniconda
• .ci/docker/build.sh: MINICONDA_VERSION=23.10.0-1 → MINIFORGE_VERSION=24.11.3-0
• .ci/docker/ubuntu/Dockerfile: ARG MINICONDA_VERSION → ARG MINIFORGE_VERSION

Test plan

Verified both Miniforge download URLs (x86_64 and aarch64) resolve correctly. The rest of the conda environment setup (Python version selection, conda-env-ci.txt, pip dependencies, libstdc++ hack) is unchanged.

[pytorch-bot]

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/executorch/18858

• 📄 Preview Python docs built from this PR

Note: Links to docs will display an error until the docs builds have been completed.

❗ 1 Active SEVs

There are 1 currently active SEVs. If your PR is affected, please view them below:

• Rolling out OSDC (ARC) runners on pull workflow for PyTorch trunk commits

⚠️ 13 Awaiting Approval

As of commit 4816246 with merge base fe71bd4 ():

AWAITING APPROVAL - The following workflows need approval before CI can run:

• Build documentation (gh)
• Build Presets (gh)
• Cadence Build & Test (gh)
• Check Labels (gh)
• docker-builds (gh)
• Lint (gh)
• periodic (gh)
• pull (gh)
• Test ARM Backend (gh)
• Test CoreML Backend (gh)
• Test QNN Backend (gh)
• Test Vulkan Backend (gh)
• Test XNNPACK Backend (gh)

This comment was automatically generated by Dr. CI and updates every 15 minutes.

[github-actions]

This PR needs a release notes: label

If your change should be included in the release notes (i.e. would users of this library care about this change?), please use a label starting with release notes:. This helps us keep track and include your important work in the next release notes.

To add a label, you can comment to pytorchbot, for example
@pytorchbot label "release notes: none"

For more information, see
https://github.com/pytorch/pytorch/wiki/PyTorch-AutoLabel-Bot#why-categorize-for-release-notes-and-how-does-it-work.

[kirklandsign]

@claude does tihs patch make sense? consider this issue

🚀 The feature, motivation and pitch
Building the CI Docker image failed with 144.7 Your usage of the Anaconda package repository exceeds our rate limits. Please see https://www.anaconda.com/tos-access.

Alternatives
Switching to miniforge should avoid the Anaconda repositories and otherwise be fully compatible.

Additional context
See https://mfisher87.github.io/posts/anaconda-tos-2024/ for details as to the rate limits for Anaconda's default repository.

[claude]

Claude finished @kirklandsign's task in 1m 14s —— View job

---

Review: Switch CI Docker image from Miniconda to Miniforge

• Read the changed files and diff
• Verify Miniforge URLs and version
• Assess correctness and completeness
• Post review feedback

---

This patch makes sense and is a clean, correct fix for the Anaconda rate-limit issue. Here's my analysis:

Changes look correct

The diff is minimal and well-scoped across the three files:

1. .ci/docker/common/install_conda.sh - Renames install_miniconda to install_miniforge, switches the download URL from repo.anaconda.com/miniconda to github.com/conda-forge/miniforge/releases, and updates the installer filename pattern. The Miniforge filename format (Miniforge3-{VERSION}-Linux-{arch}.sh) correctly differs from Miniconda's (Miniconda3-py{PYVER}_{VERSION}-Linux-{arch}.sh) - notably Miniforge doesn't embed the Python version in the filename, which is correct behavior.

2. .ci/docker/build.sh - Renames MINICONDA_VERSION=23.10.0-1 to MINIFORGE_VERSION=24.11.3-0 and passes it as the correct --build-arg.

3. .ci/docker/ubuntu/Dockerfile - ARG MINICONDA_VERSION → ARG MINIFORGE_VERSION.

No stale references

I checked the entire repo for leftover MINICONDA / miniconda / Miniconda references in .ci/ and found none. The rename is complete.

The fix_conda_ubuntu_libstdcxx hack

The libstdc++ hack at .ci/docker/common/install_conda.sh:57-68 still references "anaconda" in its comments (https://anaconda.org/anaconda/libstdcxx-ng/files?version=11.2.0). This hack removes libstdc++.so* from the conda env because conda's version is older than what Ubuntu 22.04 ships. With Miniforge using conda-forge instead of the Anaconda defaults channel, the libstdcxx-ng package may come from conda-forge with a potentially different (possibly newer) version. The hack might still be necessary, but it's worth verifying after the docker-builds CI runs. This isn't a blocker for the PR.

Minor note

The comment at line 60 (but anaconda is stuck with 3.29) could be updated to reference conda-forge, but per ExecuTorch's style guidelines preferring minimal comments, this is non-blocking.

Verdict

LGTM. The patch correctly switches from Miniconda (which uses Anaconda's default channel subject to rate limits) to Miniforge (which uses conda-forge). The change is minimal, focused, and preserves all other conda setup logic. The docker-builds CI workflow will be the definitive test.