Checked against the action repo itself rather than assumed: git ls-remote
shows v1.7.4 is the newest release tag and the moving v1 tag points at the
same commit (c2ae82f), so this changes which ref is named, not which code
runs — today. What it buys is that the version running stays the version
that was reviewed here, instead of silently following wherever v1 moves.
There was never a v0 reference in this workflow, and there is no api-key
presence check to remove — the action is invoked directly and fails loudly
if JUNIE_API_KEY is absent, which is the intended behaviour.
For the record, since this commit will re-trigger the job on PR #12: the two
failures there today are neither the workflow nor the Junie balance. Both
died in under ten seconds at the action's GitHub permission pre-check with
GitHub's own 503 body ("No server is currently available to service your
request"), before any Junie API call was made.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SAcqrz3FcadkYr3xG32CjK
Claude
f4c5e214f9