I hope these sed usages can be accepted in order to speed up the whole workflow. And this clearly demonstrates what we did.

Is the speed difference that significant? I'd rather not use the mirrors if possible to reduce the possible points of failure or things that could get out of sync.

Yes, this is one of the feasible solutions we can implement.

On the self-hosted riscv64 runners, outbound access to some upstream services can be intermittently unstable due to external network factors, which may occasionally affect CI reliability before the actual build or tests start from my experimental. In fact,localized mirror services were included as an initial goal of this project to ensure the stability of CI.

Regarding the risk of mirrors getting out of sync: these mirrors are actively maintained and have a daily synchronization mechanism to track upstream changes, along with basic health checks to ensure they remain usable. This helps reduce the risk of silent divergence.

We do not publish our mirror service in case other users abuse it to affect the stability of our CI, if necessary, we can publish it after our internal assessment.

Using these Prepare mirrored sources with sed is a more transparent approach than using a cached solution, which increases complexity. But for r-l/r, we have to depend on lots of cache strategy, If we get to that point.

Confirmed with infra on Zulip (starting around here #t-infra > RISC-V runner in compiler builtins @ 💬) that we don't want to use these mirrors. It's fine to keep around while you're still testing, but please drop them at some point.

If there's some weird circumstances making these mirrors work better than GH, bring it up on Zulip so we can see if there's something we can do.