Better docker layer caching during build

[koppor]

The JBang site is sometimes down - therefore, we need to apply a workaround.

This workournd is better caching of layers.

Steps to test

See CI passing :)

Mandatory checks

• I own the copyright of the code submitted and I license it under the MIT license
• [/] I manually tested my changes in running JabRef (always required)
• [/] I added JUnit tests for changes (if applicable)
• [/] I added screenshots in the PR description (if change is visible to the user)
• [/] I described the change in CHANGELOG.md in a way that is understandable for the average user (if change is visible to the user)
• [/] I checked the user documentation: Is the information available and up to date? If not, I created an issue at https://github.com/JabRef/user-documentation/issues or, even better, I submitted a pull request updating file(s) in https://github.com/JabRef/user-documentation/tree/main/en.

[testlens-app]

✅ All tests passed ✅

🏷️ Commit: e980ba1
▶️ Tests: 11185 executed
⚪️ Checks: 56/56 completed

---

Learn more about TestLens at testlens.app.

[koppor]

Current output:

<center><h1>502 Bad Gateway</h1></center>

Thus, config seems to be right, but some server issue

Options:

• Wait until foojay works again
• Switch back to gradle-based image - and cache JBang
• Use sdkman in docker image to setup JDK

[qodo-free-for-open-source-projects]

Review Summary by Qodo

Improve Docker build layer caching and JDK reliability

✨ Enhancement

Walkthroughs

Description

• Optimize Docker layer caching for faster builds
• Replace Gradle image with Maven/Corretto for better JDK support
• Include JBang from Docker image to avoid external dependencies
• Restructure Dockerfile COPY commands for incremental caching
• Update .dockerignore to exclude build artifacts properly
• Add GitHub Actions cache integration for Docker builds

Diagram

flowchart LR
  A["Docker Build Process"] --> B["Use Maven/Corretto Base Image"]
  A --> C["Copy JBang from Docker Image"]
  A --> D["Incremental COPY Layers"]
  B --> E["Better JDK Compatibility"]
  C --> F["Remove External Dependencies"]
  D --> G["Improved Layer Caching"]
  G --> H["Faster Rebuild Times"]

Loading

File Changes

1. .dockerignore ⚙️ Configuration changes +5/-7

Update Docker ignore patterns and exclusions

• Remove blank line and add build-logic/.gradle/ to exclusions
• Change */bin, */build, */out to **/bin, **/build, **/out for recursive matching
• Remove gradle.properties from exclusions to include it in Docker build

.dockerignore

---

2. .github/workflows/dockerimages.yml ✨ Enhancement +2/-0

Enable GitHub Actions Docker layer caching

• Add GitHub Actions cache integration with cache-from: type=gha
• Enable maximum cache mode with cache-to: type=gha,mode=max

.github/workflows/dockerimages.yml

---

3. .sdkmanrc ⚙️ Configuration changes +1/-1

Switch to Amazon Corretto JDK

• Change Java version from 25-tem (Temurin) to 25-amzn (Amazon Corretto)

.sdkmanrc

---

View more (4)

4. Dockerfile.jabkit ✨ Enhancement +35/-5

Restructure Dockerfile for optimized layer caching

• Replace gradle:jdk25-noble base image with maven:3.9.12-amazoncorretto-25-debian
• Add JBang installation from Docker image to avoid external dependency
• Restructure COPY commands into multiple layers for better caching
• Add intermediate ./gradlew || true step to cache Gradle dependencies
• Build build-logic:jar before copying full source code
• Combine final build and artifact move into single RUN command

Dockerfile.jabkit

---

5. Dockerfile.jabsrv ✨ Enhancement +35/-5

Restructure Dockerfile for optimized layer caching

• Replace gradle:jdk25-noble base image with maven:3.9.12-amazoncorretto-25-debian
• Add JBang installation from Docker image to avoid external dependency
• Restructure COPY commands into multiple layers for better caching
• Add intermediate ./gradlew || true step to cache Gradle dependencies
• Build build-logic:jar before copying full source code
• Combine final build and artifact move into single RUN command

Dockerfile.jabsrv

---

6. gradle.properties Formatting +1/-1

Fix comment typo

• Fix typo: change "Tollchains" to "Toolchains" in comment

gradle.properties

---

7. settings.gradle.kts ✨ Enhancement +1/-0

Add Foojay JDK toolchain resolver plugin

• Add Foojay resolver convention plugin for automatic JDK toolchain resolution
• Plugin version 1.0.0 enables better JDK discovery and management

settings.gradle.kts

---

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (2) 📘 Rule violations (3) 📎 Requirement gaps (0)

1. ./gradlew || true masks failures 📘 Rule violation ⛯ Reliability

Description

• The Docker build runs ./gradlew || true, which intentionally ignores Gradle failures during the
  image build.
• This can hide real build issues (e.g., broken wrapper, network/proxy issues) and makes CI/build
  outcomes harder to diagnose because the build continues after an error.
• Compliance requires failure points to be handled with actionable context rather than being
  silently ignored.

Code

Dockerfile.jabkit[20]

+RUN ./gradlew || true

Evidence

PR Compliance ID 3 forbids silent failures/ignored errors. The Dockerfiles explicitly ignore the
exit code of ./gradlew by appending || true, which will mask any failure at that step.

Rule 3: Generic: Robust Error Handling and Edge Case Management
Dockerfile.jabkit[20-20]
Dockerfile.jabsrv[20-20]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The Docker build currently runs `./gradlew || true`, which suppresses failures and can hide real problems.

## Issue Context
This appears intended as a dependency/toolchain warm-up for caching, but it should not silently ignore errors.

## Fix Focus Areas
- Dockerfile.jabkit[17-21]
- Dockerfile.jabsrv[17-21]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Unjustified Foojay plugin added 📘 Rule violation ⛯ Reliability

Description

• settings.gradle.kts adds the org.gradle.toolchains.foojay-resolver-convention plugin, which
  introduces a new build dependency.
• The PR description focuses on Docker layer caching/JBang availability, but does not provide clear
  justification for adding this plugin.
• Compliance requires new dependencies to be clearly necessary and justified in the change context.

Code

settings.gradle.kts[25]

+    id("org.gradle.toolchains.foojay-resolver-convention") version "1.0.0"

Evidence

PR Compliance ID 11 disallows introducing new dependencies without clear justification. The PR adds
a new Gradle plugin dependency in settings.gradle.kts, but the provided PR context does not
explain why it is required for the stated Docker caching workaround.

AGENTS.md
settings.gradle.kts[23-26]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
A new Gradle plugin dependency (`org.gradle.toolchains.foojay-resolver-convention`) was added without clear justification tied to the PR’s goal.

## Issue Context
If the plugin is required to make toolchain resolution reliable in Docker/CI, that should be explicitly documented; otherwise, it should be removed to avoid dependency bloat.

## Fix Focus Areas
- settings.gradle.kts[23-26]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

3. Commented-out FROM left 📘 Rule violation ✓ Correctness

Description

• The Dockerfiles add commented-out FROM ... lines representing an alternative build base image.
• Keeping commented-out code reduces maintainability and creates ambiguity about the intended build
  configuration.
• Compliance requires removing commented-out code and keeping comments focused on the "why" rather
  than preserving dead alternatives.

Code

Dockerfile.jabkit[R3-4]

+# Is not debian-based
+# FROM amazoncorretto:25-jdk AS build

Evidence

PR Compliance ID 12 requires removing commented-out code. The Dockerfiles contain commented-out
FROM lines that represent inactive code paths rather than explanatory documentation.

AGENTS.md
Dockerfile.jabkit[3-4]
Dockerfile.jabsrv[3-4]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Commented-out Dockerfile instructions were added (`# FROM ...`). These are dead code and should be removed.

## Issue Context
If an alternative base image is needed, it should be implemented explicitly (e.g., via build args/targets) or documented, not left commented-out.

## Fix Focus Areas
- Dockerfile.jabkit[3-4]
- Dockerfile.jabsrv[3-4]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

4. Gradle Xmx=6g in Docker 🐞 Bug ⛯ Reliability

Description

• Docker builds now explicitly copy the repo’s gradle.properties into the build stage and run
  Gradle, which forces org.gradle.jvmargs=-Xmx6g.
• In memory-limited Docker environments (common on developer machines / Docker Desktop), this can
  cause Gradle/JVM startup failures or OOM, making image builds flaky.
• The same pattern exists in both Dockerfile.jabkit and Dockerfile.jabsrv, so the impact is broad.

Code

Dockerfile.jabkit[R22-38]

+COPY settings.gradle.kts .
+COPY build.gradle.kts .
+COPY gradle.properties .
+COPY build-logic/ build-logic/
+COPY build-support/ build-support/
+COPY jabgui/build.gradle.kts jabgui/
+COPY jabkit/build.gradle.kts jabkit/
+COPY jablib/build.gradle.kts jablib/
+COPY jabls/build.gradle.kts jabls/
+COPY jabls-cli/build.gradle.kts jabls-cli/
+COPY jabsrv/build.gradle.kts jabsrv/
+COPY jabsrv-cli/build.gradle.kts jabsrv-cli/
+COPY test-support test-support
+COPY versions versions
+
+# Cache gradle and build-logic
+RUN ./gradlew --no-daemon :build-logic:jar

Evidence

Both Dockerfiles copy gradle.properties and then execute Gradle; gradle.properties sets a very large
heap size (6g), which will be applied inside the container for these Gradle invocations.

Dockerfile.jabkit[22-44]
Dockerfile.jabsrv[22-44]
gradle.properties[3-6]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Docker builds now copy `gradle.properties` into the build stage and run Gradle. The repo `gradle.properties` sets `org.gradle.jvmargs=-Xmx6g`, which can exceed typical Docker memory limits and make image builds fail/flaky.

## Issue Context
This affects both `Dockerfile.jabkit` and `Dockerfile.jabsrv` where Gradle is invoked multiple times.

## Fix Focus Areas
- Dockerfile.jabkit[22-44]
- Dockerfile.jabsrv[22-44]
- gradle.properties[1-6]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

5. Unpinned image digests 🐞 Bug ⛨ Security

Description

• Build stages reference external images by mutable tags (Maven base + JBang image).
• This reduces build reproducibility over time and is weaker supply-chain hygiene (especially for
  the third-party JBang image).
• Pinning to digests makes the Docker build inputs immutable and auditable.

Code

Dockerfile.jabkit[R1-12]

+FROM maven:3.9.12-amazoncorretto-25-debian AS build
+
+# Is not debian-based
+# FROM amazoncorretto:25-jdk AS build

ARG VERSION="100.0.0"
ARG VERSION_INFO="100.0.0"
ARG TAG_BUILD="false"

WORKDIR /build

-COPY . .
+COPY --from=jbangdev/jbang:0.136.0-java-21 /jbang-0.136.0/ /jbang/

Evidence

The Dockerfiles pull the build base image and copy artifacts from another image using tag-only
references rather than immutable digests.

Dockerfile.jabkit[1-13]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Docker build inputs are currently tag-pinned but not digest-pinned, which allows base images to change over time and weakens reproducibility/supply-chain guarantees.

## Issue Context
This applies to the Maven build stage base image and the JBang image used as a source for `COPY --from=...`.

## Fix Focus Areas
- Dockerfile.jabkit[1-13]
- Dockerfile.jabsrv[1-13]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

ⓘ The new review experience is currently in Beta. Learn more

[qodo-free-for-open-source-projects]

1. ./gradlew || true masks failures 📘 Rule violation ⛯ Reliability

• The Docker build runs ./gradlew || true, which intentionally ignores Gradle failures during the
  image build.
• This can hide real build issues (e.g., broken wrapper, network/proxy issues) and makes CI/build
  outcomes harder to diagnose because the build continues after an error.
• Compliance requires failure points to be handled with actionable context rather than being
  silently ignored.

Agent Prompt

## Issue description
The Docker build currently runs `./gradlew || true`, which suppresses failures and can hide real problems.

## Issue Context
This appears intended as a dependency/toolchain warm-up for caching, but it should not silently ignore errors.

## Fix Focus Areas
- Dockerfile.jabkit[17-21]
- Dockerfile.jabsrv[17-21]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

[qodo-free-for-open-source-projects]

2. Unjustified foojay plugin added 📘 Rule violation ⛯ Reliability

• settings.gradle.kts adds the org.gradle.toolchains.foojay-resolver-convention plugin, which
  introduces a new build dependency.
• The PR description focuses on Docker layer caching/JBang availability, but does not provide clear
  justification for adding this plugin.
• Compliance requires new dependencies to be clearly necessary and justified in the change context.

Agent Prompt

## Issue description
A new Gradle plugin dependency (`org.gradle.toolchains.foojay-resolver-convention`) was added without clear justification tied to the PR’s goal.

## Issue Context
If the plugin is required to make toolchain resolution reliable in Docker/CI, that should be explicitly documented; otherwise, it should be removed to avoid dependency bloat.

## Fix Focus Areas
- settings.gradle.kts[23-26]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools