Instructions for Building a Canary

[scottf]

A canary is a workflow to do something like test against this library. This is a non-production document, not intended for the average user, just documentation.

[synadia-claude-reviewer]

Claude finished @scottf's task in 1m 45s —— View job

---

PR Review

• Gather context
• Read PR changes
• Review documentation
• Post findings

---

The document is clear, well-structured, and the core logic (read jarVersion from build.gradle, append -SNAPSHOT, refresh dependencies) is sound. Two issues worth addressing:

1. Shell injection risk in single-build sed step (line 56)
The single-build variant interpolates ${{ steps.v.outputs.version }} directly into the run: shell script. The matrix variant correctly uses an env var (VERSION) which is safer. The fix is to do the same in the single-build step. See inline comment.

2. Hardcoded java-version: 25 in matrix build (line 119)
The matrix sets TARGET_COMPATIBILITY to vary across [8, 17, 21, 25] but always installs Java 25. If the intent is to test across different JDK versions, the Java version should follow the matrix value. If "compile with Java 25 but verify compatibility at level N" is the intent, a clarifying comment would prevent readers from introducing a silent bug when adapting this template. See inline comment.

Everything else looks correct: the set -euo pipefail, passing user input as an env var (INPUT_VERSION), the --refresh-dependencies rationale, fail-fast: false on the matrix, and the "nothing is committed" property of the sed-only approach.

[mtmk]

LGTM

[synadia-claude-reviewer]

The sed command directly interpolates the GitHub Actions expression ${{ steps.v.outputs.version }} into the shell command text. If the version string were to contain shell metacharacters or # (the sed delimiter used here), it could break the command or, in a worst case, allow injection.

The resolve step correctly isolates user input via an env var (INPUT_VERSION). The single-build sed step should do the same:

Suggested change

	fi
	- name: Pin jnats ${{ steps.v.outputs.version }} for this run (not committed)
	env:
	JNATS_VERSION: ${{ steps.v.outputs.version }}
	run: sed -i "s#io.nats:jnats:[^'\"]*#io.nats:jnats:${JNATS_VERSION}#" build.gradle

The matrix version already does this correctly (env: VERSION: ${{ needs.resolve.outputs.version }}).

[synadia-claude-reviewer]

The matrix job sets TARGET_COMPATIBILITY: ${{ matrix.tc }} (env var for Gradle) but hardcodes java-version: 25 for all matrix legs. If the goal is to test across different JDK versions (8, 17, 21, 25) — not just different --release compatibility flags — this should be java-version: ${{ matrix.tc }}.

If the intent is "compile with Java 25 but verify source compatibility at each level" (i.e., --release flag style), this is fine and should have a comment explaining that. As written, a reader who's adapting this for multi-JDK testing will silently always test under Java 25.

Suggested change

	strategy:
	- uses: actions/setup-java@v5
	with:
	java-version: ${{ matrix.tc }}
	distribution: temurin

(Or add a comment clarifying the hardcoded 25 is intentional.)