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
Nothing has ever checked this project automatically. There are no workflows,
so the pull request's green tick means only that the checks were run by hand
on one machine, and nothing would catch a regression pushed later.
The lockfile had to come first. `npm ci` is the only install that guarantees
CI tests the dependency tree that is actually committed, and it refuses to
run without package-lock.json — which was gitignored. Un-ignoring it also
pins the 617 packages this was built and verified against; without it, a
transitive release could change what CI runs from one day to the next with
no commit to point at. Checked before committing: every entry resolves to
registry.npmjs.org, and it carries no credentials.
Two jobs rather than one, run in parallel. The typecheck/unit/build job is
fast and deterministic; the end-to-end job drives a real headless browser
through WebGL2 software rendering and is the one that will be slow and, if
anything here is going to be flaky, flaky. Keeping them apart means a
browser timeout cannot hide a failing unit test behind it.
Between the four steps, all four TypeScript projects are compiled: the ETL
and end-to-end configs explicitly, since nothing else ever builds them, and
the spec and app configs by `ng test` and `ng build` respectively.
One thing this cannot verify from here: the runner installs Chromium to
match the pinned Playwright, where this container ships an older build. The
suite was run locally against that older browser instead, and passes.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WaySiNst4HhDXBHnMy8p5G
Claude