[ISSUE-76] Fix Gradle build failure — replace setup-java with Alpine JDK package #5

Dave · 2026-07-05T06:27:56Z

Dave commented

2026-07-05 06:27:56 +00:00

Summary

The actions/setup-java@v4 step downloads a glibc-compiled Temurin JDK, which cannot execute on Alpine's musl libc (/opt/hostedtoolcache/Java_Temurin-Hotspot_jdk/17.0.19-10/x64/bin/java: not found). This causes ./gradlew build to fail.

The fix replaces the setup-java step with Alpine's native openjdk17-jdk package (compiled for musl), and explicitly sets JAVA_HOME via $GITHUB_ENV so gradlew can find it.

Changes

Removed: actions/setup-java@v4 step (Fetches glibc Temurin JDK, incompatible with Alpine/musl)
Added: apk add --no-cache openjdk17-jdk — installs musl-native JDK 17
Added: echo "JAVA_HOME=/usr/lib/jvm/java-17-openjdk" >> "$GITHUB_ENV" — ensures gradlew can resolve JAVA_HOME

Issues

Hithomelabs/HomeLabDocker#76 — Fix Gradle build failure in CI runner test workflow

Testing

CI workflow should pass all steps including ./gradlew build
Manual verification of JDK installation on Alpine

## Summary The `actions/setup-java@v4` step downloads a glibc-compiled Temurin JDK, which cannot execute on Alpine's musl libc (`/opt/hostedtoolcache/Java_Temurin-Hotspot_jdk/17.0.19-10/x64/bin/java: not found`). This causes `./gradlew build` to fail. The fix replaces the `setup-java` step with Alpine's native `openjdk17-jdk` package (compiled for musl), and explicitly sets `JAVA_HOME` via `$GITHUB_ENV` so `gradlew` can find it. ## Changes - **Removed**: `actions/setup-java@v4` step (Fetches glibc Temurin JDK, incompatible with Alpine/musl) - **Added**: `apk add --no-cache openjdk17-jdk` — installs musl-native JDK 17 - **Added**: `echo "JAVA_HOME=/usr/lib/jvm/java-17-openjdk" >> "$GITHUB_ENV"` — ensures gradlew can resolve JAVA_HOME ## Issues - Hithomelabs/HomeLabDocker#76 — Fix Gradle build failure in CI runner test workflow ## Testing - [ ] CI workflow should pass all steps including `./gradlew build` - [ ] Manual verification of JDK installation on Alpine

Dave added 1 commit 2026-07-05 06:27:56 +00:00

Hithomelabs/HomeLabDocker#76 : Fix Gradle build failure — replace setup-java with Alpine JDK package 455505a6d6

The actions/setup-java@v4 step downloads a glibc-compiled JDK (Temurin)
which cannot execute on Alpine's musl libc. Replace with Alpine's native
openjdk17-jdk package via apk, which is compiled for musl and works
correctly with gradlew.

Linus approved these changes 2026-07-05 06:32:38 +00:00

Linus left a comment

PR Review: [ISSUE-76] Fix Gradle build failure — replace setup-java with Alpine JDK package

Summary

This PR fixes the Gradle build failure (Issue #76) by replacing actions/setup-java@v4 (which downloads a glibc-compiled Temurin JDK incompatible with Alpine/musl) with Alpine's native openjdk17-jdk package via apk, and explicitly setting JAVA_HOME so gradlew can resolve it.

Code Quality

Correct root cause identification: glibc JDK on musl Alpine → "not found" error from missing ELF interpreter
Uses apk add --no-cache — correct practice (avoids leaving APK cache)
$GITHUB_ENV is the proper mechanism for cross-step environment propagation in Gitea/GitHub Actions
JAVA_HOME path /usr/lib/jvm/java-17-openjdk matches Alpine's openjdk17 package layout

Security

No secrets exposed
No external downloads — uses Alpine's native package manager
--no-cache prevents local APK cache bloat

Concerns

1. Diff includes stale push: trigger addition
The diff shows push: trigger being added to the workflow. This change was already merged in PR #3 (ISSUE-75). The PR's base commit predates that merge. While git shows this as mergeable, the actual meaningful change is only the JDK installation replacement. The merger should be aware when squashing.

2. No inline JAVA_HOME verification after export
The JAVA_HOME is written to $GITHUB_ENV, but there's no immediate verification that it resolves correctly before the Gradle build. The existing "Verify tools" step only checks java -version (via PATH), not $JAVA_HOME/bin/java. Consider adding a quick check:

      - name: Install JDK (musl-native, Alpine package)
        run: |
          apk add --no-cache openjdk17-jdk
          echo "JAVA_HOME=/usr/lib/jvm/java-17-openjdk" >> "$GITHUB_ENV"          

      - name: Verify JAVA_HOME
        run: echo "JAVA_HOME=$JAVA_HOME && $JAVA_HOME/bin/java -version"

This is optional — the Gradle build will fail fast if JAVA_HOME is wrong — but it would provide a clearer diagnostic point if something goes wrong.

3. Image size concern (non-blocking)
The custom image is based on eclipse-temurin:17-jre-alpine, which already contains a JRE. Installing the full openjdk17-jdk adds ~200MB on top. A long-term consideration: modify the Dockerfile (#68) to use eclipse-temurin:17-jdk-alpine or pre-install openjdk17-jdk in the image itself, avoiding runtime package download.

Testing

CI workflow must pass ./gradlew build step (this is the primary validation)
JAVA_HOME should be correctly resolved by the Gradle wrapper
Docker CLI test step should still pass (no regression)
Node.js verification should still pass (no regression)

Recommendations

For the immediate fix: This PR is correct and should be approved. The apk add + JAVA_HOME export is the right approach for a musl-based Alpine CI runner.
Post-merge: Consider adding the Verify JAVA_HOME step for better debuggability.
Medium-term: Plan to migrate the base image to a glibc-based distro (Ubuntu/Debian) as suggested in the architect's notes, which would allow using setup-java and other GitHub Actions that expect glibc.

Approval Status

APPROVED — Ready for human merge (squash recommended per PR request).

The core change is technically correct and addresses the root cause. The concerns noted are non-blocking and can be addressed in follow-up work.

## PR Review: [ISSUE-76] Fix Gradle build failure — replace setup-java with Alpine JDK package ### Summary This PR fixes the Gradle build failure (Issue #76) by replacing `actions/setup-java@v4` (which downloads a glibc-compiled Temurin JDK incompatible with Alpine/musl) with Alpine's native `openjdk17-jdk` package via `apk`, and explicitly setting `JAVA_HOME` so `gradlew` can resolve it. ### Code Quality - [x] Correct root cause identification: glibc JDK on musl Alpine → "not found" error from missing ELF interpreter - [x] Uses `apk add --no-cache` — correct practice (avoids leaving APK cache) - [x] `$GITHUB_ENV` is the proper mechanism for cross-step environment propagation in Gitea/GitHub Actions - [x] `JAVA_HOME` path `/usr/lib/jvm/java-17-openjdk` matches Alpine's openjdk17 package layout ### Security - [x] No secrets exposed - [x] No external downloads — uses Alpine's native package manager - [x] `--no-cache` prevents local APK cache bloat ### Concerns **1. Diff includes stale `push:` trigger addition** The diff shows `push:` trigger being added to the workflow. This change was already merged in PR #3 (ISSUE-75). The PR's base commit predates that merge. While git shows this as mergeable, the actual meaningful change is only the JDK installation replacement. The merger should be aware when squashing. **2. No inline `JAVA_HOME` verification after export** The `JAVA_HOME` is written to `$GITHUB_ENV`, but there's no immediate verification that it resolves correctly before the Gradle build. The existing "Verify tools" step only checks `java -version` (via PATH), not `$JAVA_HOME/bin/java`. Consider adding a quick check: ```yaml - name: Install JDK (musl-native, Alpine package) run: | apk add --no-cache openjdk17-jdk echo "JAVA_HOME=/usr/lib/jvm/java-17-openjdk" >> "$GITHUB_ENV" - name: Verify JAVA_HOME run: echo "JAVA_HOME=$JAVA_HOME && $JAVA_HOME/bin/java -version" ``` This is optional — the Gradle build will fail fast if `JAVA_HOME` is wrong — but it would provide a clearer diagnostic point if something goes wrong. **3. Image size concern (non-blocking)** The custom image is based on `eclipse-temurin:17-jre-alpine`, which already contains a JRE. Installing the full `openjdk17-jdk` adds ~200MB on top. A long-term consideration: modify the Dockerfile (#68) to use `eclipse-temurin:17-jdk-alpine` or pre-install `openjdk17-jdk` in the image itself, avoiding runtime package download. ### Testing - [ ] CI workflow must pass `./gradlew build` step (this is the primary validation) - [ ] `JAVA_HOME` should be correctly resolved by the Gradle wrapper - [ ] Docker CLI test step should still pass (no regression) - [ ] Node.js verification should still pass (no regression) ### Recommendations 1. **For the immediate fix**: This PR is correct and should be approved. The `apk add` + `JAVA_HOME` export is the right approach for a musl-based Alpine CI runner. 2. **Post-merge**: Consider adding the `Verify JAVA_HOME` step for better debuggability. 3. **Medium-term**: Plan to migrate the base image to a glibc-based distro (Ubuntu/Debian) as suggested in the architect's notes, which would allow using `setup-java` and other GitHub Actions that expect glibc. ### Approval Status **APPROVED** — Ready for human merge (squash recommended per PR request). The core change is technically correct and addresses the root cause. The concerns noted are non-blocking and can be addressed in follow-up work.

Linus approved these changes 2026-07-05 06:32:43 +00:00

hitanshu requested review from hitanshu 2026-07-05 06:33:45 +00:00

hitanshu approved these changes 2026-07-05 06:34:07 +00:00

hitanshu merged commit 2d4c755cc2 into main

2026-07-05 06:34:36 +00:00

hitanshu referenced this issue from a commit

2026-07-05 06:34:37 +00:00

Merge pull request '[ISSUE-76] Fix Gradle build failure — replace setup-java with Alpine JDK package' (#5) from Dave/ci-runner-test:ISSUE-76 into main

Sign in to join this conversation.

No reviewers