Conversation
|
Claude finished @scottf's task in 2m 14s —— View job PR Review
The workflow design is solid: minimal permissions ( Medium — missing Low — shell injection via direct Everything else looks good — the |
| - name: Resolve the jnats version to test | ||
| id: v | ||
| run: | | ||
| set -uo pipefail |
There was a problem hiding this comment.
Missing -e flag. Without set -e, if curl fails (network outage, GitHub unavailable), the pipeline inside $(...) returns non-zero but the assignment itself succeeds with JARVER="". Execution continues silently and the resolve job outputs version=-SNAPSHOT, which Gradle will reject with a confusing dependency resolution error rather than a clear "couldn't fetch version" failure.
| set -uo pipefail | |
| set -euo pipefail |
| id: v | ||
| run: | | ||
| set -uo pipefail | ||
| VERSION='${{ github.event.inputs.version }}' |
There was a problem hiding this comment.
Shell injection risk: ${{ github.event.inputs.version }} is interpolated directly into the script text before the shell runs it. A value like foo' && malicious_command ' would break out of the single-quoted string.
The safe pattern is to pass the input as an environment variable so the value is never embedded in the script source:
| VERSION='${{ github.event.inputs.version }}' | |
| VERSION="${INPUT_VERSION:-}" |
And add to the job (or step) env block:
env:
INPUT_VERSION: ${{ github.event.inputs.version }}For a private repo with restricted workflow_dispatch access this is low-severity, but it's the recommended GitHub hardening practice.
|
@claude re-review |
|
Claude finished @scottf's task in 1m 47s —— View job Re-review
Both issues from the previous review have been addressed cleanly. Previous findings — resolved
The comment on line 35 ( Fresh pass — new observations Low — nats-server compiled from source on every matrix leg Lines 74-79 run - name: Install Nats Server
run: |
NATS_VER=$(curl -sf https://api.github.com/repos/nats-io/nats-server/releases/latest | grep -oP '"tag_name": "\K[^"]+')
curl -sfL "https://github.com/nats-io/nats-server/releases/download/${NATS_VER}/nats-server-${NATS_VER}-linux-amd64.tar.gz" \
| tar -xz --strip-components=1 -C ~/.local/bin nats-server-${NATS_VER}-linux-amd64/nats-server
nats-server -vThis is a performance note, not a correctness issue — the build-from-source approach is correct and more likely to catch integration issues with the very latest nats-server. Informational — The binary is installed to Overall The two issues from the prior review are properly resolved. The workflow design is sound: correct permissions ( |
Addresses #22
Adds a scheduled GitHub Actions workflow (jnats-canary.yml) that builds and runs the full test suite against jnats' current main snapshot once a day, across all supported Java target levels (8, 17, 21, 25).
Why
java-active-passive is tightly coupled to jnats, so a change upstream can break us before we've bumped our pinned version. This canary catches that early — we find out the morning after a breaking jnats change, in our own CI, rather than when we go to adopt a release.
How
It reads jnats' current version from jnats main, tests against -SNAPSHOT (rewriting the dependency for the run only — nothing committed), and reports green/red. No credentials and no changes on the jnats side — it just reads jnats' public published artifacts. A status badge in the README shows the current state at a glance, and GitHub emails on failure.
Etc.
Can be run on demand from the Actions tab, optionally against a specific version (e.g. to vet a jnats release before adopting it).