We would like to support and backport together with the original author ( @fmeum ) the Remote Repository Contents Cache feature from Bazel v9 to v8. This feature is not dependent on bzlmod, but it was introduced as part of the v9.0.0 release and therefore cannot be used with a workspace file. We would like to align with the Bazel maintainers and their roadmap to integrate these changes in way that maximizes their likeliness to be accepted.
Large Bazel projects are likely not able to migrate to bzlmod in a timely fashion. Due to their nature they often contain large sets of external dependencies, or have internal priorities that are of higher perceived value. That makes them good candidates to benefit from the Remote Repository Contents Cache feature in Bazel v8 as well.
Our point of view
We (ASML) are still on Bazel v8. This is due to internal politics and milestones, and it is something that we only might be able to change just before the Bazel v8 end of support hits.
Our external dependencies (toolchains) are growing at a rate that is causing problems in throughput (downloading), storage and parsing; before and during the analysis phase. We build for >10 target platforms at the same time (i.e. X64, PPC64) , with multiple package versions. Each of these packages can be very large (>10GB) and we cannot slim them down due to licensing. All said and done, the total size of the uncompressed package dependencies in a single workspace can go as large as 250GB.
There are several ways to mitigate this problem without backporting the Remote Repository Contents Cache, however they are likely to solve the problem only in one of our environments (i.e. CI) and not all (e.g. developer). Our goal is to align with Bazel v9 (and the roadmap of the project) instead of introducing new dependencies on technology that do not contribute to the bzlmod migration (e.g. asset-fuse).
We would like to support and backport together with the original author ( @fmeum ) the Remote Repository Contents Cache feature from Bazel v9 to v8. This feature is not dependent on bzlmod, but it was introduced as part of the v9.0.0 release and therefore cannot be used with a workspace file. We would like to align with the Bazel maintainers and their roadmap to integrate these changes in way that maximizes their likeliness to be accepted.
Large Bazel projects are likely not able to migrate to bzlmod in a timely fashion. Due to their nature they often contain large sets of external dependencies, or have internal priorities that are of higher perceived value. That makes them good candidates to benefit from the Remote Repository Contents Cache feature in Bazel v8 as well.
Our point of view
We (ASML) are still on Bazel v8. This is due to internal politics and milestones, and it is something that we only might be able to change just before the Bazel v8 end of support hits.
Our external dependencies (toolchains) are growing at a rate that is causing problems in throughput (downloading), storage and parsing; before and during the analysis phase. We build for >10 target platforms at the same time (i.e. X64, PPC64) , with multiple package versions. Each of these packages can be very large (>10GB) and we cannot slim them down due to licensing. All said and done, the total size of the uncompressed package dependencies in a single workspace can go as large as 250GB.
There are several ways to mitigate this problem without backporting the Remote Repository Contents Cache, however they are likely to solve the problem only in one of our environments (i.e. CI) and not all (e.g. developer). Our goal is to align with Bazel v9 (and the roadmap of the project) instead of introducing new dependencies on technology that do not contribute to the bzlmod migration (e.g. asset-fuse).