Repository navigation
Tags
Tags
ci: answer Corepack's download prompt before it asks Corepack asks the terminal to confirm downloading the pinned pnpm whenever it is not already cached, and a runner has no terminal to answer with: Node aborts on the closed stdin and the step exits 1. It broke the Windows leg today and passed on a re-run, because a cache hit is what decides.
The upgrade check runs before the tag, not after it Only the stale-index half needs a live PyPI. The mechanics — does every package move together, does the installed binary find its plugins — need the wheels step 4 already built, so they belong where the tag can still be moved.
A report cut off mid-write is a sentence, not a stack trace Windows has no signals: `process.kill(pid, "SIGKILL")` there is `TerminateProcess(handle, 1)`, so a tool killed halfway through writing its report exits 1 — which is exactly what eslint and knip exit when they found something to report. Nothing upstream can tell the two apart, so the half- written array reached `JSON.parse` and both sensors answered a reader with a `SyntaxError` and four frames of Node. Reading a tool's report is the seam's question for the same reason running it and describing its failure already were: both callers need the same answer, and the last time one of them was left to decide for itself was habit-hooks#142. A run that printed plenty and left nothing usable says so, rather than borrowing the words for one that said nothing at all. The test that found this now asserts both platforms rather than the one the author's machine could produce.
release: 1.4.0rc2, and the placeholder is where an author would look …
…for it
Three commits since rc1, all in the same 1.4.0: a sensor names the tool it wraps,
the cmd.exe argument guard reaches the tool a helper spawns, and a mistyped argv
answers with a sentence rather than a traceback.
The changelog keeps one section rather than gaining a second. rc1 and rc2 are
candidates for the same release, and three headings for one release is what the
stale Unreleased section did to 1.0.x.
${detector:<name>} joins the placeholder list in the authoring manual, in both
recipe forms, with the example every shipped sensor now follows. Section 3 still
teaches wrapping a tool as a jq pipeline, which 1.4.0 deleted — that is habit-hooks#141 and
predates this.
The floors are untouched. >=1.4.dev0,<2 serves the rc and the final release
alike, which is the point of that spelling.
ci: pin the publish action by commit, not by its tag object The v1.14.2 bump used the annotated tag object SHA. The action runs ghcr.io/pypa/gh-action-pypi-publish:<that sha>, and images are published per commit, so every job died with `manifest unknown` after the build had already run. Pinned to the commit v1.14.2 points at, and confirmed the ghcr manifest resolves for it (200) where the tag object does not (404).
PreviousNext