Chore: reuse shared 'setup-gradle' in all places in test-code.yml

[jjohannes]

I noticed that there was one place in the GH actions setup where the ./.github/actions/setup-gradle is not used, but instead the gradle/actions/setup-gradle@v5 is used directly. I assume this is not intentional (?). This PR adjusts this one line in test-code.yml.

Steps to test

This is tested by the GH actions running on this PR.

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)
• 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.

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

Review Summary by Qodo

Reuse shared setup-gradle action in test-code workflow

✨ Enhancement

Walkthroughs

Description

• Consolidate Gradle setup to use shared action
• Replace direct gradle/actions/setup-gradle with local wrapper
• Improve consistency across CI workflow

Diagram

flowchart LR
  A["test-code.yml workflow"] -- "previously used" --> B["gradle/actions/setup-gradle@v5"]
  A -- "now uses" --> C["./.github/actions/setup-gradle"]
  C -- "wraps" --> B

Loading

File Changes

1. .github/workflows/tests-code.yml ⚙️ Configuration changes +1/-2

Replace direct Gradle action with shared wrapper

• Replaced direct gradle/actions/setup-gradle@v5 with local ./.github/actions/setup-gradle
 wrapper
• Removed explicit step name "Setup Gradle" for consistency
• Maintains same functionality while improving workflow consistency

.github/workflows/tests-code.yml

---

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

Code Review by Qodo

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

1. Unpinned JBang action 🐞 Bug ⛨ Security

Description

• After switching to the composite ./.github/actions/setup-gradle, this job now runs
  jbangdev/setup-jbang@main.
• Referencing an external action by a moving branch (@main) is a supply-chain and reliability risk
  (upstream changes can break CI or introduce unexpected behavior).
• While this unpinned reference pre-exists in the composite action, this PR expands its usage to the
  requirements_coverage job, increasing the blast radius.

Code

.github/workflows/tests-code.yml[554]

+      - uses: ./.github/actions/setup-gradle

Evidence

The job now uses the composite action, and the composite action includes an unpinned external action
reference (@main). Therefore, the job inherits this risk as a direct consequence of the PR change.

.github/workflows/tests-code.yml[551-555]
.github/actions/setup-gradle/action.yml[39-40]

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 composite action `./.github/actions/setup-gradle` uses `jbangdev/setup-jbang@main`, which is a moving target and creates supply-chain and CI stability risks. This PR makes `requirements_coverage` depend on that unpinned action.

### Issue Context
Even if the composite action is local, it still pulls and executes external actions. Pinning to a tag/SHA reduces risk and prevents unexpected breakages.

### Fix Focus Areas
- .github/actions/setup-gradle/action.yml[39-40]
- .github/workflows/tests-code.yml[551-555]

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

---

✅ 2. Redundant Java setup 🐞 Bug ⛯ Reliability

---

Suggestion Impact:

The workflow’s explicit `Set up JDK` (`actions/setup-java@v5`) step was removed from `requirements_coverage`, leaving Java setup to be handled only by the `./.github/actions/setup-gradle` composite action and eliminating the duplicate Java configuration.

code diff:

-      - name: Set up JDK
-        uses: actions/setup-java@v5
-        with:
-          java-version: 25
-          distribution: 'corretto'
-          check-latest: true
       - uses: ./.github/actions/setup-gradle

Description

• The requirements_coverage job configures Java, then invokes ./.github/actions/setup-gradle,
  which configures Java again.
• This adds CI time and creates a maintenance trap: future changes to the job’s Java setup can be
  silently overridden by the composite action’s Java defaults (last setup-java wins).
• The PR change makes the job effectively depend on the composite action’s Java configuration rather
  than the job-local one.

Code

.github/workflows/tests-code.yml[R551-554]

          java-version: 25
          distribution: 'corretto'
          check-latest: true
-      - name: Setup Gradle
-        uses: gradle/actions/setup-gradle@v5
+      - uses: ./.github/actions/setup-gradle

Evidence

The job still contains an explicit actions/setup-java@v5 configuration, but after the PR change it
also calls a composite action that itself runs actions/setup-java@v5, resulting in two Java setups
in sequence.

.github/workflows/tests-code.yml[541-555]
.github/actions/setup-gradle/action.yml[17-25]

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 `requirements_coverage` job runs `actions/setup-java` and then calls `./.github/actions/setup-gradle`, which also runs `actions/setup-java`. This duplicates work and can override the job’s intended Java settings.

### Issue Context
The PR replaced a direct `gradle/actions/setup-gradle@v5` step with the composite action. The composite action currently always sets up the JDK.

### Fix Focus Areas
- .github/workflows/tests-code.yml[548-555]
- .github/actions/setup-gradle/action.yml[14-40]

ⓘ 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. Unpinned jbang action 🐞 Bug ⛨ Security

• After switching to the composite ./.github/actions/setup-gradle, this job now runs
  jbangdev/setup-jbang@main.
• Referencing an external action by a moving branch (@main) is a supply-chain and reliability risk
  (upstream changes can break CI or introduce unexpected behavior).
• While this unpinned reference pre-exists in the composite action, this PR expands its usage to the
  requirements_coverage job, increasing the blast radius.

Agent Prompt

### Issue description
The composite action `./.github/actions/setup-gradle` uses `jbangdev/setup-jbang@main`, which is a moving target and creates supply-chain and CI stability risks. This PR makes `requirements_coverage` depend on that unpinned action.

### Issue Context
Even if the composite action is local, it still pulls and executes external actions. Pinning to a tag/SHA reduces risk and prevents unexpected breakages.

### Fix Focus Areas
- .github/actions/setup-gradle/action.yml[39-40]
- .github/workflows/tests-code.yml[551-555]

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

[koppor]

Both work.... Here, I had speed in mind. However, consitency is maybe more important 😅

[koppor]

Neeed to address #15043 (comment)

[testlens-app]

✅ All tests passed ✅

🏷️ Commit: 528e46b
▶️ Tests: 11185 executed
⚪️ Checks: 52/52 completed

---

Learn more about TestLens at testlens.app.