Junie has been reviewing pull requests here since the key was added, and eight
of the last eight runs succeeded. What it was not, was configured like the
sibling repositories, and three of those differences are worth closing.
The action was referenced as `@v1`. It is the only third-party action in this
repository and the only one handed a repository secret, so its definition
should not be able to change under us. `v1` and `v1.7.5` resolve to the same
commit today — the pin is not about which code runs now, it is about who gets
to decide that later.
There was no timeout. A run that goes wrong hangs rather than stops, and the
pull request shows a pending check until Actions gives up on its own six hours
later. Forty-five minutes, not the thirty the siblings use: the longest review
this repository has actually had ran thirty-five, on the largest diff so far,
and a ceiling that cuts a successful review short is worse than none.
And a pull request closed and reopened had had no review since it was closed.
Left alone deliberately: the absent-key step, which says so in the run summary
instead of failing a pull request for a reason that has nothing to do with its
code, and the lack of a `branches:` filter — work here stacks feature onto
feature, and filtering on main would skip every pull request in a chain but the
last.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016jxMkwA2rbicdGxHosecYi
The workflow as written failed on ddf805e: with no JUNIE_API_KEY secret the
input expands to empty and the action exits on "Missing required input",
marking the pull request failed for a reason that has nothing to do with its
code. I called it inert without the key. It was not inert; it was red, and it
would have been red on every pull request until someone added the secret.
So gate the steps on the key's presence and write the reason into the run
summary instead. `secrets` is not a context a step's `if` can read and neither
`secrets` nor `env` is available to a job-level `if`, so the presence is
resolved once into a job-level env var, which steps can read.
The action step also gets continue-on-error: an outage or a rate limit at
JetBrains' end is worth seeing in the log, but this workflow is meant to be an
opinion beside CI rather than a gate in front of it, and a failure to obtain
that opinion should not hold a pull request whose tests pass.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WaySiNst4HhDXBHnMy8p5G
CI says whether the code works. Nothing says whether it reads well, and the
one review this repository has had so far arrived by hand.
Kept as a separate workflow rather than a third job in ci.yml so a review can
never turn the build red — the two answer different questions and should be
able to disagree.
It skips drafts, and skips pull requests from forks: GitHub withholds secrets
from `pull_request` runs on a forked head, so the job would fail on a missing
JUNIE_API_KEY rather than say anything about the code. Each push supersedes
the previous review rather than stacking another comment beside it.
Requires a JUNIE_API_KEY repository secret, generated at
junie.jetbrains.com/cli. Without it the workflow is inert.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WaySiNst4HhDXBHnMy8p5G
SenrokaiandClaude Fable 5