CI failure: Task `riscv32 bare metal, static libbitcoin_consensus`: submodule cloning rate limited #35853

Not sure what to do about this. Looks like some projects blocked CI machines from cloning their repos.

🚧 At least one of the CI tasks failed. _{Task riscv32 bare metal, static libbitcoin_consensus: https://github.com/bitcoin/bitcoin/actions/runs/30046119080/job/90826618769} _{LLM reason (✨ experimental): CI failed because submodule cloning of newlib-cygwin.git from sourceware.org was rate-limited (HTTP 429), causing the base install step to exit with code 2.}

Originally posted by @DrahtBot in #35762 (comment)

Related: https://github.com/riscv-collab/riscv-gnu-toolchain/issues/1883

The CI is now failing for more than a week, and it is unclear when it will be coming back. I think it makes sense to at least temporarily remove the config from the GHA matrix.

edit: done in https://github.com/bitcoin/bitcoin/pull/35875

I have managed (after a struggle) to mirror the sourceware repos on my own infra here: https://git.fish.foo/mirrors

We could switch to that in CI with a rough patch like:

 ${CI_RETRY_EXE} git clone --depth=1 https://github.com/riscv-collab/riscv-gnu-toolchain -b 2026.06.06 /riscv/gcc
+# Use a mirror for these submodules as sourceware blocks too many requests.
+git config --global \
+  url."https://git.fish.foo/mirrors/binutils-gdb.git".insteadOf \
+  "https://sourceware.org/git/binutils-gdb.git"
+
+git config --global \
+  url."https://git.fish.foo/mirrors/glibc.git".insteadOf \
+  "https://sourceware.org/git/glibc.git"
+
+git config --global \
+  url."https://git.fish.foo/mirrors/newlib-cygwin.git".insteadOf \
+  "https://sourceware.org/git/newlib-cygwin.git"
+
 ( cd /riscv/gcc;
   ./configure --prefix=/opt/riscv-ilp32 --with-arch=rv32gc --with-abi=ilp32 --disable-gdb;
   make "$MAKEJOBS"; )

This of course only moves the potential source of flakiness from sourceware.org to myself. I have no plans to deprecate that forgejo instance and can probably be more responsive to fixing things that sourceware appear to be, but perhaps there is still another better solution...

I have a local branch combining this with caching both the SDKs (a la #35722) and the riscv toolchain build more cleanly in CI, so I may close #35722 and open a "unified" approach, if using my mirror repos is deemed acceptable?

Using fish foo seems fine. Should be trivial to remove the config (cherry-pick fa06ea42448d94c6e7ed9fad1adedb439ff6f78d) if something fails again.

Waiting a few more weeks for upstream seems also fine.

I wouldn't combine the change with other changes, though.

Closing now as #35885 is merged.

If that's not deemed a robust-enough fix we can re-open.

Looks like upstream has switch to mirrors: https://github.com/riscv-collab/riscv-gnu-toolchain/commit/92d239130d237017f8dabb7556c355bb7bde3f38

I guess b283e1751cc48b247d500cb5a642561d10651f16 can be reverted, then?

great!

I can revert this, but are we happy to pin to a master commit on riscv-gnu-toolchain, or shall we wait until they cut a nightly tag?