8000 Tags · habit-hooks/habit-hooks · GitHub
[go: up one dir, main page]

Skip to content

Tags

Tags

v1.5.0

Toggle v1.5.0's commit message
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.

v1.4.0

Toggle v1.4.0's commit message
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.

v1.4.0rc3

Toggle v1.4.0rc3's commit message
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 #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.

v1.4.0rc2

Toggle v1.4.0rc2's commit message
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 #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.

v1.4.0rc1

Toggle v1.4.0rc1's commit message
1.4.0rc1 — native Windows support

v1.3.1

Toggle v1.3.1's commit message
1.3.1

v1.3.0

Toggle v1.3.0's commit message
release: 1.3.0

The java plugin is the release. Every package ships at 1.3.0 and the core's
plugin floors move to ~=1.3 with it, so `pip install -U habit-hooks` upgrades
the plugins alongside the core rather than leaving last release's behind.

v1.2.1

Toggle v1.2.1's commit message
1.2.1

v1.2.0

Toggle v1.2.0's commit message
1.2.0

v1.1.0

Toggle v1.1.0's commit message
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).
0