Fix CI

[koppor]

Summary

The gradle jbang plugin doesn't find our cached JBang file. This PR tries to fix it.

• Uses Google's Maven Central Mirror
• Scopes JBang cache to OS (to workaround some JDK symlink issues)
• Fixes JBang usage by the JBang gradle plugin

Steps to test

See no error on version.txt any more.

Related issues and pull requests

Closes NA

jbangdev/jbang-gradle-plugin#25

AI usage

Claude guided me somehow.

Checklist

• I own the copyright of the code submitted and I license it under the MIT license
• If AI tools were used, I disclosed them in the "AI usage" section and reviewed, understood, and take full ownership of all AI-generated code
• [/] 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 added a screenshot in the PR description showing a library with a single entry with me as author and as title the issue number
• [/] I described the change in CHANGELOG.md in a way that can be understood by the average user (if change is visible to the user)
• [/] I checked the user documentation for up to dateness and submitted a pull request to our user documentation repository

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

PR Summary by Qodo

Stabilize CI by fixing JBang caching, pinning JBang, and using Maven Central mirror

🐞 Bug fix ⚙️ Configuration changes 🕐 20-40 Minutes

AI Description

• Add explicit JBang caching and repo routing for jobs invoking jbang directly.
• Pin JBang version for Gradle JBangTasks to avoid flaky latest/version.txt fetches.
• Use Google’s Maven Central mirror to reduce CI failures from Central rate limiting (HTTP 429).

Diagram

graph TD
  A["GitHub Actions CI"] --> B{ "Runs Gradle?" }
  B -->|"Yes"| C["setup-gradle action"] --> D["JBANG_REPO -> Gradle caches"] --> E["Gradle JBangTask"] --> F{{"Maven Central (Google mirror)"}}
  B -->|"No (shell jbang)"| G["Cache ~/.jbang"] --> H["Setup JBang"] --> I["JBANG_REPO -> ~/.jbang/repository"] --> J["jbang build/run"] --> F
  subgraph Legend
    direction LR
    _ci["CI/Job"] ~~~ _act["Action/Step"] ~~~ _cache[("Cache/Repo Dir")] ~~~ _ext{{"External repo"}}
  end

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Standardize on one cache location (Gradle user home) for all JBang usage

• ➕ Single cache surface area; simpler to reason about than mixing ~/.jbang and ~/.gradle.
• ➕ Leverages setup-gradle’s built-in cache behavior for most jobs.
• ➖ Shell-driven jobs would need extra logic to compute native paths on Windows (already noted).
• ➖ Requires changing composite actions/workflows currently caching ~/.jbang explicitly.

2. Install JBang explicitly for all jobs (avoid dev.jbang plugin auto-install/path misses)

• ➕ Avoids the PATH-miss behavior that triggers latest/version.txt fetches.
• ➕ More uniform environment setup across jobs.
• ➖ More setup time if caching is missed; duplicates functionality the plugin already provides.
• ➖ Doesn’t address where //DEPS artifacts land unless JBANG_REPO is still set.

3. Use an internal Maven proxy (Nexus/Artifactory) instead of a public mirror

• ➕ Full control over rate limiting, availability, and auditing.
• ➕ Can cache more than Maven Central (plugins, snapshots, etc.).
• ➖ Operational overhead and credentials/secrets management.
• ➖ Harder for forks/community CI if access is restricted.

Recommendation: The PR’s approach is a pragmatic CI-hardening bundle: pinning JBang removes a known flaky network call, and routing //DEPS into cached directories reduces repeated downloads. If CI stability remains an issue, the next simplification would be consolidating shell-driven jobs onto the same Gradle-user-home cache (with Windows-native path handling), and pinning jbangdev/setup-jbang to a SHA for determinism.

Files changed (7) +95 / -20

Bug fix (1) +9 / -0

build.gradle.ktsPin JBang version for Gradle JBangTask generators +9/-0

Pin JBang version for Gradle JBangTask generators

• Introduces a pinned 'jbangVersion' and assigns it to all 'JBangTask' registrations. This avoids dev.jbang plugin network calls to 'releases/latest/.../version.txt' on PATH misses, improving CI reliability.

jablib/build.gradle.kts

Other (6) +86 / -20

action.ymlCache ~/.jbang and route //DEPS to cached repo for jbang-check +19/-0

Cache ~/.jbang and route //DEPS to cached repo for jbang-check

• Adds a monthly cache key and caches '~/.jbang' for the composite action. Sets 'JBANG_REPO' to '~/.jbang/repository' so script '//DEPS' resolve into the cached directory before running build and launcher checks.

.github/actions/jbang-check/action.yml

action.ymlStop installing/caching JBang; set JBANG_REPO into Gradle caches (OS-aware) +15/-14

Stop installing/caching JBang; set JBANG_REPO into Gradle caches (OS-aware)

• Renames the composite action to JDK+Gradle only and removes JBang setup/cache steps. Introduces 'JBANG_REPO' pointing into the Gradle user home cache, with separate handling for Windows native paths via PowerShell.

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

pr-comment.ymlInstall/cache JBang directly for ghprcomment job (no Gradle) +25/-2

Install/cache JBang directly for ghprcomment job (no Gradle)

• Replaces 'setup-gradle' usage with explicit Java setup plus JBang caching and setup. Routes 'JBANG_REPO' to '~/.jbang/repository' so ghprcomment’s '//DEPS' downloads reuse the same cache.

.github/workflows/pr-comment.yml

tests-code.ymlFix JBang caching steps and publish snapshots into JBang repo +13/-4

Fix JBang caching steps and publish snapshots into JBang repo

• Adds 'JBANG_REPO=~/.jbang/repository' to JBang-using jobs so '//DEPS' artifacts land in the cached directory. Switches a restore-only cache step to the combined cache action, and publishes 'jablib' snapshots into the same repo used by JBang checks via '-Dmaven.repo.local'.

.github/workflows/tests-code.yml

build.gradle.ktsAdd Google Maven Central mirror to reduce HTTP 429 failures +6/-0

Add Google Maven Central mirror to reduce HTTP 429 failures

• Prepends Google’s Maven Central mirror to build-logic repositories to mitigate Maven Central rate limiting encountered via Gradle plugin resolution redirects.

build-logic/build.gradle.kts

renovate.jsonTeach Renovate to update the pinned JBang version in Gradle script +8/-0

Teach Renovate to update the pinned JBang version in Gradle script

• Adds a custom regex manager to detect and update 'val jbangVersion = "..."' in 'jablib/build.gradle.kts' using GitHub releases metadata.

renovate.json

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

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. Cache overwrites snapshot ✓ Resolved 🐞 Bug ≡ Correctness

Description

The new jbang-check composite action restores ~/.jbang from cache, and in the jbang-pr job jablib is
published to $HOME/.jbang/repository immediately before invoking that action; on a cache hit, the
restore can overwrite the freshly published 6.0-SNAPSHOT with an older cached snapshot, making the
JBang scripts validate stale code.

Code

.github/actions/jbang-check/action.yml[R13-16]

+      uses: actions/cache@v6
+      with:
+        path: ~/.jbang
+        key: ${{ steps.cache-key.outputs.cache_key }}

Evidence

The composite action restores ~/.jbang (including ~/.jbang/repository) right before running
JBang; the PR workflow publishes jablib into that same directory before invoking the action, so a
cache hit can overwrite those just-written files with cached content at the same paths (notably
6.0-SNAPSHOT).

.github/actions/jbang-check/action.yml[6-24]
.github/workflows/tests-code.yml[548-556]

Agent prompt

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

## Issue description
`./.github/actions/jbang-check` restores the entire `~/.jbang` directory via `actions/cache@v6`. In `tests-code.yml` the `jbang-pr` job publishes `jablib` into `~/.jbang/repository` **before** invoking `jbang-check`, so any cache hit can restore older files over the just-published SNAPSHOT and cause JBang script checks to run against stale artifacts.
### Issue Context
- `jbang-pr` publishes to `-Dmaven.repo.local="$HOME/.jbang/repository"` so scripts can pick up `6.0-SNAPSHOT`.
- `jbang-check` restores `~/.jbang` (which includes `~/.jbang/repository`) when it starts.
### Fix Focus Areas
- Remove cache restore/save from the composite action and do caching in the calling workflow **before** the publish step:
- .github/actions/jbang-check/action.yml[6-24]
- .github/workflows/tests-code.yml[521-556]
#### One concrete approach
1) In `.github/actions/jbang-check/action.yml`, delete the "Generate JBang cache key" and "Cache JBang" steps (keep `JBANG_REPO` and `setup-jbang`).
2) In `.github/workflows/tests-code.yml`, add the same cache-key + `actions/cache@v6` steps near the start of both `jbang-main` and `jbang-pr` jobs (after checkout), so the restore happens before any publish to `~/.jbang/repository`.
3) Ensure the cache `path` remains `~/.jbang` so it’s still saved post-job, but the restore no longer happens after publishing.

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

---

2. jbangVersion defined in module ✓ Resolved 📘 Rule violation ⚙ Maintainability

Description

The JBang version is pinned via a local val jbangVersion = ... inside jablib/build.gradle.kts
rather than being managed in the centralized versions/build.gradle.kts, which fragments version
management and makes upgrades/audits harder.

Code

jablib/build.gradle.kts[107]

+val jbangVersion = "0.141.0"

Evidence

PR Compliance ID 2 requires versions to be managed centrally (e.g., versions/build.gradle.kts)
rather than ad-hoc in build logic. The PR adds val jbangVersion = "0.141.0" in
jablib/build.gradle.kts and uses it to configure multiple JBangTask instances, while
versions/build.gradle.kts is the established central location for version pins.

AGENTS.md: Declare and manage dependencies via module-info.java, versions/build.gradle.kts, and gradle/modules.properties: AGENTS.md: Declare and manage dependencies via module-info.java, versions/build.gradle.kts, and gradle/modules.properties: AGENTS.md: Declare and manage dependencies via module-info.java, versions/build.gradle.kts, and gradle/modules.properties: AGENTS.md: Declare and manage dependencies via module-info.java, versions/build.gradle.kts, and gradle/modules.properties
jablib/build.gradle.kts[103-147]
versions/build.gradle.kts[11-32]

Agent prompt

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

## Issue description
`jablib/build.gradle.kts` introduces a standalone `val jbangVersion = "0.141.0"` for configuring `JBangTask.version`. Per repository conventions, versions should be centralized (rather than pinned ad-hoc in a module build file).
## Issue Context
The repo already centralizes many version pins in `versions/build.gradle.kts`. Keeping the JBang version there (or an equivalent central version catalog used by the project) avoids drift and makes Renovate/updates consistent.
## Fix Focus Areas
- jablib/build.gradle.kts[103-147]
- versions/build.gradle.kts[11-32]

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

---

3. Unpinned setup-jbang action ✓ Resolved 🐞 Bug ⛨ Security

Description

New CI steps use jbangdev/setup-jbang@main, which is a moving ref; upstream changes can alter what
code runs in CI without any change or review in this repository.

Code

.github/actions/jbang-check/action.yml[R23-24]

+    - name: Setup JBang
+      uses: jbangdev/setup-jbang@main

Evidence

The PR introduces new usages of jbangdev/setup-jbang@main in the composite action and the
pr-comment workflow, while the repo already pins the same action to a commit SHA elsewhere,
indicating pinning is feasible and preferred here too.

.github/actions/jbang-check/action.yml[23-24]
.github/workflows/pr-comment.yml[141-166]
.github/workflows/tests-code.yml[259-262]

Agent prompt

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

## Issue description
`jbangdev/setup-jbang@main` is used in newly added/updated CI paths. Using a moving branch ref reduces reproducibility and increases supply-chain risk.
### Issue Context
This repo already demonstrates the preferred pattern (pinning `setup-jbang` to a commit SHA with a tag comment) in another workflow job.
### Fix Focus Areas
- Replace `@main` with a reviewed commit SHA (optionally add a comment noting the release/tag):
- .github/actions/jbang-check/action.yml[23-24]
- .github/workflows/pr-comment.yml[160-166]
### Implementation notes
- Pick a specific commit from `jbangdev/setup-jbang` (e.g., the commit corresponding to a released tag) and use `uses: jbangdev/setup-jbang@<sha>`.
- Optionally align with the already-pinned style used elsewhere:
- .github/workflows/tests-code.yml[259-262]

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

---

Tip of the day

💡 Did you know, you can type 'qodo, fix this' on a finding and the fix lands right on your PR

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗