Skip to content

ci: use the GitHub Actions cache on hosted runners only - #33

Merged
hbrombeer merged 1 commit into
mainfrom
ci/no-gha-cache-self-hosted
Sep 30, 2026
Merged

hbrombeer merged 1 commit into
mainfrom
ci/no-gha-cache-self-hosted

Conversation

@hbrombeer

Copy link
Copy Markdown
Member

gradle-ci.yml, gradle-publish.yml and docker-gradle-build-push.yml: setup-java's cache: gradle and setup-gradle's cache now apply only when runner.environment == 'github-hosted'. On the hbr1 pools they are off.

Why: the Actions cache is downloaded from Azure blob storage. From hbr1 it stalled at 0 bytes for minutes and then crawled at ~1 MB/s (grounds-portal setup-node, 2026-09-30, 287 MB). Measured from the same pods: nodejs.org 24 MB/s, registry.npmjs.org 15 MB/s. The cache is slower than resolving from scratch. The layer cache had the same problem (#29/#31).

Self-hosted Gradle jobs keep the remote build cache node (GRADLE_BUILD_CACHE_URL). publish-openapi-snapshot.yml runs on hosted runners and is unchanged.

Test: test_gradle_caches_are_used_on_hosted_runners_only (9/9 green).

From the self-hosted runners on hbr1 the Actions cache stalled at 0 bytes
for minutes and then crawled at about 1 MB/s (setup-node's npm cache in
grounds-portal, 2026-09-30). That is slower than resolving from scratch.

Gate setup-java's gradle cache and setup-gradle's cache on
runner.environment. Self-hosted jobs use the Gradle build cache node the
runners advertise.
@hbrombeer
hbrombeer merged commit da40db8 into main Sep 30, 2026
3 checks passed
@hbrombeer
hbrombeer deleted the ci/no-gha-cache-self-hosted branch September 30, 2026 11:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant