Chore: add 'testlens-app/setup-testlens' GH action

[jjohannes]

As discussed with @koppor this onboard the JabRef/jabref project for the TestLens private beta. The action requires the TestLens App to be installed on this repository, which is already done.

The app posts a summary of all test failures as a PR comment and provides means to mute unrelated test failures and faster reruns. For more information, please refer to the announcement on our website.

For questions and feedback, please contact me directly or open an issue.

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

Integrate TestLens GitHub action for test monitoring

✨ Enhancement

Walkthroughs

Description

• Integrates TestLens GitHub action for test failure analysis
• Enables automated test summary comments on pull requests
• Provides test failure muting and faster rerun capabilities

Diagram

flowchart LR
  A["Gradle Setup Action"] --> B["Setup JDK"]
  B --> C["Setup Gradle"]
  C --> D["Setup TestLens"]
  D --> E["Test Monitoring & Reporting"]

Loading

File Changes

1. .github/actions/setup-gradle/action.yml ✨ Enhancement +2/-0

Add TestLens action to Gradle setup workflow

• Added TestLens setup step to the Gradle setup action workflow
• Integrated testlens-app/setup-testlens@v1 action after Gradle setup
• Enables automated test failure analysis and PR comments
• Requires TestLens App to be installed on the repository

.github/actions/setup-gradle/action.yml

---

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

Code Review by Qodo

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

1. Env bound to TestLens 🐞 Bug ✓ Correctness

Description

• GRADLE_BUILD_ACTION_CACHE_DEBUG_ENABLED is now applied to the new “Setup TestLens” step, not to
  the “Setup Gradle” step.
• This silently changes CI behavior: any intended configuration of gradle/actions/setup-gradle via
  that env var will no longer take effect.
• Because this composite action is used across many workflows, the impact applies broadly to CI
  runs.

Code

.github/actions/setup-gradle/action.yml[R23-28]

    - name: Setup Gradle
      uses: gradle/actions/setup-gradle@v5
+    - name: Setup TestLens
+      uses: testlens-app/setup-testlens@v1
      env:
        GRADLE_BUILD_ACTION_CACHE_DEBUG_ENABLED: true

Evidence

The env: block is indented under the new TestLens step (not under the Gradle setup step). The
Gradle step ends at line 24 with no env: attached, so the variable will not be provided to that
action.

.github/actions/setup-gradle/action.yml[23-28]

Agent prompt

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

### Issue description
`GRADLE_BUILD_ACTION_CACHE_DEBUG_ENABLED` is currently scoped to the new `Setup TestLens` step due to YAML indentation, meaning it will not be applied to the `gradle/actions/setup-gradle` step anymore.

### Issue Context
This composite action is reused across multiple workflows; a small scoping change has repo-wide CI impact.

### Fix Focus Areas
- .github/actions/setup-gradle/action.yml[23-28]

### Implementation notes
- If the env var is intended for `gradle/actions/setup-gradle`, indent/move the `env:` block under the `Setup Gradle` step.
- If it’s intended to be global for subsequent Gradle invocations, consider setting it in the calling workflows’ job/step `env` instead.

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

---

2. Unpinned TestLens action 🐞 Bug ⛨ Security

Description

• The newly introduced testlens-app/setup-testlens@v1 uses a mutable tag, increasing supply-chain
  risk (the referenced code can change without a PR).
• The repo already demonstrates SHA-pinning for at least some third-party actions, so this is
  inconsistent with existing practice.

Code

.github/actions/setup-gradle/action.yml[R25-26]

+    - name: Setup TestLens
+      uses: testlens-app/setup-testlens@v1

Evidence

The composite action references testlens-app/setup-testlens via @v1. Elsewhere in the repo, a
third-party action is pinned to an immutable commit SHA, demonstrating an existing precedent for
stronger pinning.

.github/actions/setup-gradle/action.yml[25-26]
.github/workflows/binaries.yml[450-453]

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 new dependency `testlens-app/setup-testlens@v1` is a mutable reference. Pinning reduces the risk of unexpected upstream changes and supply-chain attacks.

### Issue Context
This action is introduced inside a shared composite action, so it will run in many workflows.

### Fix Focus Areas
- .github/actions/setup-gradle/action.yml[25-26]

### Implementation notes
- Replace `@v1` with `@<full_commit_sha>`.
- Add a short comment mapping the SHA back to the release/tag for maintainability.
- Dependabot is already configured for `github-actions` updates; it can keep the SHA current.

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

---

3. Shared action blast radius 🐞 Bug ⛯ Reliability

Description

• Adding TestLens inside the shared setup-gradle composite action makes many workflows depend on
  the availability/behavior of a new external action.
• This increases CI coupling for unrelated pipelines (e.g., publish and multi-OS binaries) even if
  they don’t need TestLens.
• Consider making TestLens opt-in (input flag) or enabling it only in workflows that actually
  consume its output.

Code

.github/actions/setup-gradle/action.yml[R25-26]

+    - name: Setup TestLens
+      uses: testlens-app/setup-testlens@v1

Evidence

Workflows across the repo call ./.github/actions/setup-gradle. Because the new TestLens step is
unconditional inside that composite action, it will execute in all those workflows, including
sensitive pipelines like publish and cross-platform binaries.

.github/actions/setup-gradle/action.yml[23-29]
.github/workflows/tests-code.yml[49-56]
.github/workflows/publish.yml[93-101]
.github/workflows/binaries.yml[332-375]
.github/workflows/binaries.yml[429-431]

Agent prompt

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

### Issue description
`Setup TestLens` is now an unconditional step inside a widely used composite action, increasing CI coupling and introducing a new external dependency for many workflows.

### Issue Context
`./.github/actions/setup-gradle` is used in tests, publish, SBOM generation, and cross-platform binaries builds.

### Fix Focus Areas
- .github/actions/setup-gradle/action.yml[4-45]
- .github/workflows/tests-code.yml[49-70]
- .github/workflows/publish.yml[93-102]
- .github/workflows/binaries.yml[332-375]

### Implementation notes
- Add a composite action input (e.g., `enableTestLens`, default `false`).
- Guard the TestLens step with `if: ${{ inputs.enableTestLens == 'true' }}`.
- Turn it on only in the specific workflows/jobs that need TestLens.

ⓘ 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

[testlens-app]

✅ All tests passed ✅

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

---

Learn more about TestLens at testlens.app.