… does this PR do? Configure GitLab `bazel*` caches on ephemeral runners to use a `pull`-only policy by default, and `pull-push` only when running on the `main` branch.

This restriction applies only to **GitLab** caches - at this stage, the `bazel` **remote** cache remains indeed shared across all branches.

### Motivation
1. avoid cache pollution from feature and release branches while allowing `main` to populate the cache in a _progressive_ manner,
2. because the GitLab cache is uploaded to a shared S3 bucket, restricting uploads to `main` reduces S3 write contention and costs incurred by parallel cache overwrites.

Because the GitLab cache is shared across pipelines, allowing feature or release branches to push artifacts pollutes the cache with _experimental_ entries from feature branches and _meanwhile-evicted_ entries from oldest release branches.

### Additional Notes
Release branches and feature branches _behind_ `main` may fetch _older_ dependencies, whereas feature branches _ahead_ of `main` may fetch _newer_ dependencies, but:
- they'll still benefit from the `bazel` remote cache,
- they'll no longer incur the overhead of uploading GitLab caches.

Co-authored-by: regis.desgroppes <[email protected]>
(cherry picked from commit 0463d57)

___

Co-authored-by: Régis Desgroppes <[email protected]>

…#46179)

Backport 0463d57 from #46151.

 ___

### What does this PR do?
Configure GitLab `bazel*` caches on ephemeral runners to use a `pull`-only policy by default, and `pull-push` only when running on the `main` branch.

This restriction applies only to **GitLab** caches - at this stage, the `bazel` **remote** cache remains indeed shared across all branches.

### Motivation
1. avoid cache pollution from feature and release branches while allowing `main` to populate the cache in a _progressive_ manner,
2. because the GitLab cache is uploaded to a shared S3 bucket, restricting uploads to `main` reduces S3 write contention and costs incurred by parallel cache overwrites.

Because the GitLab cache is shared across pipelines, allowing feature or release branches to push artifacts pollutes the cache with _experimental_ entries from feature branches and _meanwhile-evicted_ entries from oldest release branches.

### Additional Notes
Release branches and feature branches _behind_ `main` may fetch _older_ dependencies, whereas feature branches _ahead_ of `main` may fetch _newer_ dependencies, but:
- they'll still benefit from the `bazel` remote cache,
- they'll no longer incur the overhead of uploading GitLab caches.

Co-authored-by: axel.vonengel <[email protected]>

… does this PR do? Configure GitLab `bazel*` caches on ephemeral runners to use a `pull`-only policy by default, and `pull-push` only when running on the `main` branch.

This restriction applies only to **GitLab** caches - at this stage, the `bazel` **remote** cache remains indeed shared across all branches.

### Motivation
1. avoid cache pollution from feature and release branches while allowing `main` to populate the cache in a _progressive_ manner,
2. because the GitLab cache is uploaded to a shared S3 bucket, restricting uploads to `main` reduces S3 write contention and costs incurred by parallel cache overwrites.

Because the GitLab cache is shared across pipelines, allowing feature or release branches to push artifacts pollutes the cache with _experimental_ entries from feature branches and _meanwhile-evicted_ entries from oldest release branches.

### Additional Notes
Release branches and feature branches _behind_ `main` may fetch _older_ dependencies, whereas feature branches _ahead_ of `main` may fetch _newer_ dependencies, but:
- they'll still benefit from the `bazel` remote cache,
- they'll no longer incur the overhead of uploading GitLab caches.

Co-authored-by: regis.desgroppes <[email protected]>
(cherry picked from commit 0463d57)

___

Co-authored-by: Régis Desgroppes <[email protected]>

…#46325)

Backport 0463d57 from #46151.

 ___

### What does this PR do?
Configure GitLab `bazel*` caches on ephemeral runners to use a `pull`-only policy by default, and `pull-push` only when running on the `main` branch.

This restriction applies only to **GitLab** caches - at this stage, the `bazel` **remote** cache remains indeed shared across all branches.

### Motivation
1. avoid cache pollution from feature and release branches while allowing `main` to populate the cache in a _progressive_ manner,
2. because the GitLab cache is uploaded to a shared S3 bucket, restricting uploads to `main` reduces S3 write contention and costs incurred by parallel cache overwrites.

Because the GitLab cache is shared across pipelines, allowing feature or release branches to push artifacts pollutes the cache with _experimental_ entries from feature branches and _meanwhile-evicted_ entries from oldest release branches.

### Additional Notes
Release branches and feature branches _behind_ `main` may fetch _older_ dependencies, whereas feature branches _ahead_ of `main` may fetch _newer_ dependencies, but:
- they'll still benefit from the `bazel` remote cache,
- they'll no longer incur the overhead of uploading GitLab caches.

Co-authored-by: florent.clarret <[email protected]>

### What does this PR do?
Wire up `bazel`-managed Go and `pip` caches to `XDG_CACHE_HOME` in the
bazel wrapper scripts, and adds the corresponding paths to the
progressive GitLab runner cache keyed on `.go-version` and
`.python-version`:
```diff
-.bazel:defs:cache:ephemeral
+.bazel:defs:cache:progressive
```

(my bad, "ephemeral" was kind of misleading: indeed used by ephemeral
_runners_, but not ephemeral in itself since it's _stored_ to S3)

### Motivation
Extend #43274's XDG-as-single-cache-root design to Go and `pip`, whose
XDG support has been steadlessly growing from "Partial" to "Supported":
https://wiki.archlinux.org/title/XDG_Base_Directory.

By landing in `$XDG_CACHE_HOME`, they inherit the progressive-cache
policy from #46151: only main pushes to them, keeping growth bounded.
Keying on language version files further contains growth by resetting
the cache at upgrade boundaries rather than accumulating superseded
artifacts.

### Additional Notes
No worry: the new cache paths are already excluded from omnibus source
trees via `**/.cache/**/*` source filters.

Coming soon: we might want to leverage upcoming `--strict_repo_env`
(with `bazel` 8.6+), for which we'll anyway have to list allowed
environment variables.

Near future: as the omnibus-bazel transition progresses, other caches
(`cache_omnibus_ruby_deps`, `go_deps`, `go_tools_deps`,
`go_tools_deps_arm64`, etc.) are expected to shrink until no longer
applicable.

### What does this PR do?
```diff
-.bazel:defs:cache:ephemeral
+.bazel:defs:cache:progressive
```

### Motivation
My bad, "ephemeral" was kind of misleading: admittedly used by ephemeral
_runners_, but not ephemeral in itself since it's stored to S3.

### Additional Notes
"progressive" better reflects the controlled policy introduced in #46151:
only `main` pushes to the cache, keeping it growing incrementally rather
than going back and forth depending on the last pushing branch - whether
antiquated or exploratory.

### What does this PR do?
```diff
-.bazel:defs:cache:ephemeral
+.bazel:defs:cache:progressive
```

### Motivation
My bad, "ephemeral" was kind of misleading: admittedly used by ephemeral
_runners_, but not ephemeral in itself since it's stored to S3.

### Additional Notes
"progressive" better reflects the controlled policy introduced in #46151:
only `main` pushes to the cache, keeping it growing incrementally rather
than going back and forth depending on the last pushing branch - whether
antiquated or exploratory.

### What does this PR do?
Wire up `bazel`-managed Go and `pip` caches to `XDG_CACHE_HOME` in the
bazel wrapper scripts, and adds the corresponding paths to the
progressive GitLab runner cache keyed on `.go-version` and
`.python-version`.

### Motivation
Extend #43274's XDG-as-single-cache-root design to Go and `pip`, whose
XDG support has been steadlessly growing from "Partial" to "Supported":
https://wiki.archlinux.org/title/XDG_Base_Directory.

By landing in `$XDG_CACHE_HOME`, they inherit the progressive-cache
policy from #46151: only `main` pushes to them, keeping growth bounded.
Keying on language version files further contains growth by resetting
the cache at version upgrade boundaries rather than accumulating
superseded artifacts.

### Additional Notes
No worry: the new cache paths are already excluded from omnibus source
trees via `**/.cache/**/*` source filters.

Coming soon: we might want to leverage upcoming `--strict_repo_env`
(with `bazel` 8.6+), for which we'll anyway have to list allowed
environment variables.

Near future: as the omnibus-bazel transition progresses, other caches
(`cache_omnibus_ruby_deps`, `go_deps`, `go_tools_deps`,
`go_tools_deps_arm64`, etc.) are expected to shrink until no longer
applicable.

### What does this PR do?
Wire up `bazel`-managed Go and `pip` caches to `XDG_CACHE_HOME` in the
`tools/bazel*` scripts, and add the corresponding paths to the
progressive GitLab runner cache keyed on `.go-version` and
`.python-version`.

### Motivation
Extend #43274's XDG-as-single-cache-root design to Go and `pip`, whose
XDG support has been steadlessly growing from "Partial" to "Supported":
https://wiki.archlinux.org/title/XDG_Base_Directory.

By landing in `$XDG_CACHE_HOME`, they inherit the progressive-cache
policy from #46151: only `main` pushes to them, keeping growth bounded.
Keying on language version files further contains growth by resetting
the cache at version upgrade boundaries rather than accumulating
superseded artifacts.

### Additional Notes
No worry: the new cache paths are already excluded from omnibus source
trees via `**/.cache/**/*` source filters.

Coming soon: we might want to leverage upcoming `--strict_repo_env`
(with `bazel` 8.6+), for which we'll anyway have to list allowed
environment variables.

Near future: as the omnibus-bazel transition progresses, other caches
(`cache_omnibus_ruby_deps`, `go_deps`, `go_tools_deps`,
`go_tools_deps_arm64`, etc.) are expected to shrink until no longer
applicable.

### What does this PR do?
Wire up `bazel`-managed Go and `pip` caches to `XDG_CACHE_HOME` in the
`tools/bazel*` scripts, and add the corresponding paths to the
progressive GitLab runner cache keyed on `.go-version` and
`.python-version`.

### Motivation
Extend #43274's XDG-as-single-cache-root design to Go and `pip`, whose
XDG support has been steadlessly growing from "Partial" to "Supported":
https://wiki.archlinux.org/title/XDG_Base_Directory.

By landing in `$XDG_CACHE_HOME`, they inherit the progressive-cache
policy from #46151: only `main` pushes to them, keeping growth bounded.
Keying on language version files further contains growth by resetting
the cache at version upgrade boundaries rather than accumulating
superseded artifacts.

### Additional Notes
No worry: the new cache paths are already excluded from omnibus source
trees via `**/.cache/**/*` source filters.

Coming soon: we might want to leverage upcoming `--strict_repo_env`
(with `bazel` 8.6+), for which we'll anyway have to list allowed
environment variables.

Near future: as the omnibus-bazel transition progresses, other caches
(`cache_omnibus_ruby_deps`, `go_deps`, `go_tools_deps`,
`go_tools_deps_arm64`, etc.) are expected to shrink until no longer
applicable.

### What does this PR do?
Wire up `bazel`-managed Go and `pip` caches to `XDG_CACHE_HOME` in the
`tools/bazel*` scripts, and add the corresponding paths to the
progressive GitLab runner cache keyed on `.go-version` and
`.python-version`.

### Motivation
Extend #43274's XDG-as-single-cache-root design to Go and `pip`, whose
XDG support has been steadlessly growing from "Partial" to "Supported":
https://wiki.archlinux.org/title/XDG_Base_Directory.

By landing in `$XDG_CACHE_HOME`, they inherit the progressive-cache
policy from #46151: only `main` pushes to them, keeping growth bounded.
Keying on language version files further contains growth by resetting
the cache at version upgrade boundaries rather than accumulating
superseded artifacts.

### Additional Notes
No worry: the new cache paths are already excluded from omnibus source
trees via `**/.cache/**/*` source filters.

Coming soon: we might want to leverage upcoming `--strict_repo_env`
(with `bazel` 8.6+), for which we'll anyway have to list allowed
environment variables.

Near future: as the omnibus-bazel transition progresses, other caches
(`cache_omnibus_ruby_deps`, `go_deps`, `go_tools_deps`,
`go_tools_deps_arm64`, etc.) are expected to shrink until no longer
applicable.

### What does this PR do?
Wire up `bazel`-managed Go and `pip` caches to `XDG_CACHE_HOME` in the `tools/bazel*` scripts, and add the corresponding paths to the progressive GitLab runner cache keyed on `.go-version` and `.python-version`.

### Motivation
Extend #43274's XDG-as-single-cache-root design to Go and `pip`, whose XDG support has been steadlessly growing from "Partial" to "Supported": https://wiki.archlinux.org/title/XDG_Base_Directory.

By landing in `$XDG_CACHE_HOME`, they inherit the progressive-cache policy from #46151: only `main` pushes to them, keeping growth bounded.
Keying on language version files further contains growth by resetting the cache at version upgrade boundaries rather than accumulating superseded artifacts.

### Additional Notes
No worry: the new cache paths are already excluded from omnibus source trees via `**/.cache/**/*` source filters.

Coming soon: we might want to leverage upcoming `--strict_repo_env` (with `bazel` 8.6.0, #47011), for which we'll anyway have to list propagated environment variables.

Near future: as the omnibus-bazel transition progresses, other caches (`cache_omnibus_ruby_deps`, `go_deps`, `go_tools_deps`, `go_tools_deps_arm64`, etc.) are expected to shrink until no longer applicable.

Co-authored-by: regis.desgroppes <[email protected]>