ci(release): fail on a commit release-please would silently drop, and provision the anchor key without displaying it - #9957
Merged
Conversation
Deploying with
|
| Status | Name | Latest Commit | Preview URL | Updated (UTC) |
|---|---|---|---|---|
| ✅ Deployment successful! View logs |
loopover-ui | 167b233 | Commit Preview URL Branch Preview URL |
Jul 30 2026, 09:49 PM |
Contributor
|
Caution 🛑 LoopOver review result - fixes requiredReview updated: 2026-07-30 22:27:55 UTC
Review summary Nits — 6 non-blocking
CI checks failing
Decision drivers
Context & advisory signals — never blocks the verdict
Linked issue satisfactionPartially addressed Review context
Contributor next steps
Signal definitions
🧪 Chat with LoopOverAsk LoopOver a question about this PR directly in a comment — grounded only in the same cached, public-safe facts shown above, never a new claim.
Full command reference: https://loopover.ai/docs/loopover-commands 🧪 Experimental — new and may change. Decision record
Visual preview
Click any thumbnail to open the full-size screenshot. Before = production · After = this PR's preview deploy. Scroll preview
A short scroll-through clip (desktop) — click either thumbnail to open the full animation. Evidence for scroll-linked behavior a single screenshot can't show. 🟩 Safe / merged · 🟦 Advisory · 🟨 Held for review · 🟥 Blocked / closed 💰 Earn for open-source contributions like this. Gittensor lets GitHub contributors earn for the work they already do — register to start earning →. Checked by LoopOver, a quiet PR intelligence layer for OSS maintainers.
|
Contributor
|
Superagent didn't find any vulnerabilities or security issues in this PR. |
Bundle ReportChanges will increase total bundle size by 2.15kB (0.03%) ⬆️. This is within the configured threshold ✅ Detailed changes
Affected Assets, Files, and Routes:view changes for bundle: loopover-uiAssets Changed:
|
JSONbored
force-pushed
the
fix/release-please-commit-parsing-9948
branch
from
July 30, 2026 21:14
6b82e81 to
dfe8aec
Compare
Refs #9948. release-please DROPS a commit whose title it cannot parse -- no version bump, no changelog entry -- and the job still reports success. Two shipped fix(miner) commits were invisible to the release when this was found, and the only evidence was buried in the run's logs. The shape is a double reference suffix, '(#9679) (#9905)', which this repo produces whenever a PR title already carries the issue number and the merge appends the PR number. Checked BEFORE release-please runs rather than by scraping its logs afterwards: a title is a fact available at commit time, and a guard on the input is one nobody has to remember to read. Scoped to the commits a branch adds over its base, NOT to everything since the last release tag. Git history is immutable and main already carries two titles of this shape, so a check that failed on those would be permanently red, would block every unrelated PR, and would be switched off within a day. Guarding new commits stops the class going forward, which is the only thing a pre-merge gate can honestly do about titles that already shipped. The pattern is deliberately narrow -- it matches the one shape observed to break the parser rather than reimplementing the conventional-commits grammar, which would drift from the real parser and start rejecting titles release-please handles fine.
Refs #9940. The keygen printed the private key to stdout, so provisioning meant a human copying a signing key out of a terminal -- where it lands in scrollback, in shell history if piped, and in whatever captured the session. One of ours had to be discarded for exactly that reason. `--secret-file <path>` writes the private half directly at 0600 and prints only the public half, which is meant to be published. Nothing to copy, nothing to leak. Point LOOPOVER_LEDGER_ANCHOR_PRIVATE_KEY_FILE at the path -- the generic <NAME>_FILE mechanism every self-host secret already supports -- and recreate the container. Refuses to overwrite an existing file: replacing a live signing key strands every anchor published under it, which is the same reason a retired key is closed rather than removed. The printing mode stays for reading the shape before provisioning.
JSONbored
force-pushed
the
fix/release-please-commit-parsing-9948
branch
from
July 30, 2026 21:30
dfe8aec to
a6bbd98
Compare
Refs #9948. release-please DROPS a commit it cannot parse -- it contributes to neither the version bump nor the changelog -- and the run still reports success. Two shipped fix(miner) commits were invisible to the release when this was found. The first cut of this guard matched the double issue/PR suffix in the subject, '(#9679) (#9905)', because that is what the failing commits visibly had in common. Driving release-please's actual parser proves that shape parses fine. The real trigger is NESTED PARENTHESES IN THE BODY, and it is position-sensitive -- the parser reports a column, and the same nested text parses when it sits further along the line. That guard would have caught nothing while reading as protection, which is worse than no guard. So this matches nothing. It runs the parser release-please itself uses and asserts every commit on the branch survives it, with release-please added as a devDependency and its own exported type used for the signature so an upgrade that changes the API is a build error rather than a silently-wrong cast. Scoped to the branch's own commits: history is immutable, and a check that failed on what already shipped would be permanently red and switched off within a day. A fixture holds the real dropped message, with a regression test asserting it STILL fails to parse -- so if an upgrade ever fixes the parser, that test goes red and says the guard can be relaxed, rather than silently protecting nothing.
JSONbored
changed the title
Contributor
Superagent Supply Chain ScanSuperagent flagged 1 dependency introduced by this pull request. Risk:
|
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #9957 +/- ##
==========================================
+ Coverage 91.87% 92.15% +0.27%
==========================================
Files 928 831 -97
Lines 113697 90708 -22989
Branches 27421 23513 -3908
==========================================
- Hits 104460 83591 -20869
+ Misses 7936 5994 -1942
+ Partials 1301 1123 -178
Flags with carried forward coverage won't be shown. Click here to find out more. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #9948.
The silent failure
release-please drops a commit it cannot parse — it contributes to neither the version bump nor the changelog — and the run still reports success. Two shipped
fix(miner):commits were invisible to the release when this was found; the only evidence was a line buried in the job's logs.I guarded the wrong thing first
Both failing commits ended in a double issue/PR suffix —
(#9679) (#9905)— so that is what my first cut matched. Driving release-please's actual parser proves that shape is fine:(#9679) (#9905)`existsSync(resolveEventLedgerDbPath(env))`at body col 1foo(bar(baz))in the bodyfoo(bar)in the bodyThe real trigger is nested parentheses in the body, and it is position-sensitive — the parser names a column (
unexpected token '(' at 12:37), and the identical text parses when shifted right.A regex cannot express that. My original guard would have caught nothing while reading as protection, which is worse than no guard at all.
So it matches nothing
It runs the parser release-please itself uses and asserts every commit on the branch survives it. release-please is a devDependency, and its own exported type is used for the signature so an API change on upgrade is a build error rather than a silently-wrong cast.
Scoped to the branch's own commits: history is immutable,
mainalready carries messages that drop, and a check failing on those would be permanently red and switched off within a day.A fixture holds the real dropped message with a regression test asserting it still fails to parse — so if an upgrade ever fixes the parser, that test goes red and tells us the guard can be relaxed, instead of silently protecting nothing.
Also here: provisioning the anchor key without ever displaying it
The keygen printed a private key to stdout, so provisioning meant copying a signing key out of a terminal — into scrollback, shell history, and whatever captured the session. One of ours had to be discarded for exactly that reason during this work.
--secret-file <path>writes the private half at0600and prints only the public half. It refuses to overwrite an existing file, since replacing a live signing key strands every anchor published under it.Validation
release-commit-parsing:check,checkers-wired,import-specifiers,dead-exports,dead-source-files,publishable-deps,workspace-dep-ranges,turbo-inputs,docs:drift-check,typecheckall pass.