CI: setup-java v5 and Gradle build cache #20

2026-09-26T01:35:42Z

selimaj-dev commented

2026-09-26 01:35:42 +00:00

Summary

setup-java v4 → v5 in the release and check workflows. v4 is deprecated, and every run logged a warning about it. It keeps cache: gradle.
Gradle build cache (org.gradle.caching=true): task outputs such as compiled classes are restored from cache when their inputs haven't changed. Locally, after clean, :mc-1.21.11:compileJava was restored FROM-CACHE in 1 s instead of compiling in 9 s.

Why builds were slow

In every run so far, cache: gradle failed against the runner's built-in cache server:

::warning::Failed to restore: getCacheEntry failed: connect ETIMEDOUT 10.0.5.2:35103   (~4.5 min)
::warning::Failed to save: reserveCache failed: connect ETIMEDOUT 10.0.5.2:35103      (~6 min)

Job containers ran on a different Docker network from the runner, so they couldn't reach the cache server. About 10.5 of the release's 18.5 minutes were timeouts, and nothing was ever cached. The build itself was ~7.5 min, starting cold every time.

The runner is now fixed: job containers join Gitea's network (container.network), and the cache server is advertised as gitea-runner:8088. This PR's Check run is the first test:

Set up Java 21 should take seconds, with a cache miss on the first run and Cache saved in the post step.
The next run should restore the Gradle cache and build much faster.

🤖 Generated with Claude Code

## Summary - **`setup-java` v4 → v5** in the release and check workflows. v4 is deprecated, and every run logged a warning about it. It keeps `cache: gradle`. - **Gradle build cache** (`org.gradle.caching=true`): task outputs such as compiled classes are restored from cache when their inputs haven't changed. Locally, after `clean`, `:mc-1.21.11:compileJava` was restored `FROM-CACHE` in 1 s instead of compiling in 9 s. ## Why builds were slow In every run so far, `cache: gradle` failed against the runner's built-in cache server: ``` ::warning::Failed to restore: getCacheEntry failed: connect ETIMEDOUT 10.0.5.2:35103 (~4.5 min) ::warning::Failed to save: reserveCache failed: connect ETIMEDOUT 10.0.5.2:35103 (~6 min) ``` Job containers ran on a different Docker network from the runner, so they couldn't reach the cache server. About **10.5 of the release's 18.5 minutes were timeouts**, and nothing was ever cached. The build itself was ~7.5 min, starting cold every time. The runner is now fixed: job containers join Gitea's network (`container.network`), and the cache server is advertised as `gitea-runner:8088`. **This PR's Check run is the first test:** - `Set up Java 21` should take seconds, with a cache miss on the first run and `Cache saved` in the post step. - The **next** run should restore the Gradle cache and build much faster. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

selimaj-dev added 1 commit 2026-09-26 01:35:42 +00:00

Move setup-java to v5 and enable Gradle's build cache

Check / compile (pull_request) Successful in 9m39s

Details

2ecb4f80ea

- setup-java v4 is deprecated; use v5 (still with `cache: gradle`,
  which works once job containers can reach the runner's cache server).
- Enable Gradle's build cache (org.gradle.caching) so unchanged
  compilations are restored from cache instead of re-run.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

selimaj-dev added 1 commit 2026-09-26 01:59:22 +00:00

Run the compile check on pull requests only, not on merges

Check / compile (pull_request) Successful in 10m49s

Details

ff0bce4d24

A merge to master re-ran the same compile the PR had just done. Keep
the pull_request trigger and drop the push-to-master one.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

selimaj-dev merged commit 04e7064790 into master

2026-09-26 02:10:44 +00:00

selimaj-dev deleted branch ci-caching

2026-09-26 02:10:47 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: saturnclientmc/saturnclient#20