chore(release): cut mcp v3.1.1 - #7087
Closed
JSONbored wants to merge 1 commit into
Closed
Conversation
Contributor
|
Superagent didn't find any vulnerabilities or security issues in this PR. |
loopover-orb
Bot
added
the
gittensor:bug
Contributor
|
Note LoopOver command help
Command: Command resultCommands
Findings
Evidence
Next actions
Source and freshness
Additional safe details
Feedback
💰 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. |
Owner
Author
5 tasks
philluiz2323
pushed a commit
to philluiz2323/gittensory
that referenced
this pull request
Jul 17, 2026
…rsions @loopover/mcp and @loopover/miner are both live on npm at 3.1.1 (published via an out-of-band manual release cut, JSONbored#7064), but .release-please-manifest.json was never updated to match -- it still recorded 3.1.0 as the last-released version for both. release-please used that stale baseline to recompute and re-propose "cut v3.1.1" as a brand-new release (JSONbored#7086, JSONbored#7087), which would fail on publish: npm rejects republishing an already-published version.
4 tasks
luciferlive112116
pushed a commit
to luciferlive112116/gittensory
that referenced
this pull request
Jul 17, 2026
The actual root cause of the mcp/miner v3.1.x release churn: engine's release and its dependents' (mcp, miner both carry a real runtime `dependencies` entry on it) release each landed as SEPARATE PRs/commits. release-please's node-workspace plugin still bumped a dependent's `@loopover/engine` version range the moment engine's version changed, but on the dependent's OWN branch -- so the dependent's package.json ended up requiring an engine version that existed nowhere (not locally, since engine's bump lived on a different unmerged branch; not on npm, since it hadn't published yet). `npm ci` failed with ETARGET until a human manually walked engine through to publish first, then updated the dependent's branch -- confirmed live across JSONbored#7086/JSONbored#7087/JSONbored#7107/JSONbored#7108. merge: true is the plugin's own purpose-built mechanism for exactly this: it combines a package with the dependents its OWN dependency-bump logic pulled in as candidates into ONE PR/commit, so engine's new version and its dependents' bumped ranges land together atomically. npm workspaces then resolves the dependency from the LOCAL checkout, which always satisfies the range regardless of npm registry publish timing or ordering -- eliminating the failure mode structurally rather than papering over it with an after-the-fact branch-update step. ui-kit has no dependency edge to any other package here, so it's never pulled into the merge and keeps its fully independent release cadence.
galuis116
pushed a commit
to galuis116/gittensory
that referenced
this pull request
Jul 18, 2026
…nd-editing it JSONbored#7100 fixed the immediate mismatch by hand-typing corrected version numbers into .release-please-manifest.json -- exactly the failure mode that caused the drift in the first place (a human-authored value instead of one derived from source of truth). This replaces that with a real mechanism: - scripts/sync-release-manifest.mjs treats each package's own package.json "version" as authoritative and syncs the manifest to match -- `npm run release-manifest:sync` is now the only supported way to fix drift, never a manual edit. - `npm run release-manifest:sync:check` (wired into both test:ci and .github/workflows/ci.yml, gated on backend/mcp/engine/miner/ui) fails CI the moment the manifest and a package.json disagree, instead of surfacing days later as release-please re-proposing an already-published version (JSONbored#7086/JSONbored#7087). - .release-please-manifest.json and release-please-config.json are now part of the `backend` path filter so editing either alone still triggers the check. Also corrects reference.md's CI check table, which still claimed manifest:drift-check/engine-parity:drift-check weren't wired into ci.yml -- stale since JSONbored#7067 actually added them.
JSONbored
added a commit
that referenced
this pull request
Jul 29, 2026
…t's independent cadence Review catch on #9753: contract was left out of the "engine-and-dependents" linked-versions group on the reasoning that it should version independently "like ui-kit". That reasoning was wrong, and this repo has already paid for the bug it reintroduces. mcp-release-please.yml's own header is explicit about what the group is for: mcp/miner carry a REAL runtime `dependencies` entry, so node-workspace bumps their range the moment the prerequisite's version changes -- and under separate-pull-requests: true that bump lands on the dependent's OWN branch, leaving its package.json requiring a version that exists nowhere (not locally, since the prerequisite's bump is on a different unmerged branch; not on npm, since it hasn't published). `npm ci` then fails ETARGET. That was confirmed live across several release cycles (#7086/#7087/#7107/#7108/#7119/#7120/#7121), and node-workspace's own `merge` option was already tried and does NOT override separate-pull-requests. ui-kit is outside the group because it has NO dependency edge to anything here -- not because independent versioning is the default. contract has exactly the edge engine has, so it belongs in the group for exactly the same reason. Membership tracks the dependency edge, not release cadence; the header now says so, since "publish it like ui-kit" is the trap that produced this. The reconciliation ordering added in this PR stays: the group fixes the release-PR stage (ranges and versions land in one commit), reconciliation fixes the publish stage (registry propagation and dispatch ordering). Engine needs both today and contract needs both for the same reasons. Cost of the fix, stated plainly: contract joins the group's version train rather than staying at 0.1.0, so its next release will not be 0.2.0. That is a worse version story than independence and a better correctness story, and 0.1.0 is already published either way.
11 tasks
JSONbored
added a commit
that referenced
this pull request
Jul 29, 2026
…omation (#9753) * ci(release): wire @loopover/contract into the release and publish automation @loopover/contract is a runtime `dependencies` entry of both @loopover/mcp and @loopover/miner, but it had no publish path — no publish workflow, and no entry in release-please's config or manifest. It was the only workspace package shaped for publishing (no `private: true`, `publishConfig.access: public`, a `files` allowlist) with no automation behind it. Left alone, the next mcp/miner release ships uninstallable: both are at 3.15.2 locally against 3.14.x on npm, so the pending publish already carries `"@loopover/contract": "^0.1.0"` against a package that did not exist. 0.1.0 has now been bootstrap-published by hand (npm's OIDC trusted publishing cannot create a brand-new package, the same bootstrap @loopover/engine needed), and a Trusted Publisher is configured against publish-contract.yml — so renaming that file breaks the connection and every publish with it. publish-contract.yml mirrors publish-engine.yml/publish-ui-kit.yml: unprivileged validate resolves the version, verifies the commit is on main, resolves the release commit from the version string rather than tagging HEAD (#8525), builds, packs, and smoke-tests; privileged publish tags and pushes the exact tested tarball via OIDC behind environment `release`. No separate typecheck step — this package's `build` IS `tsc -p tsconfig.json`. The secret scan needed one deliberate change. Unlike its siblings, this package SHIPS the redaction logic: dist/telemetry.js defines SECRET_VALUE_PATTERN, whose source text contains a literal PEM `PRIVATE KEY` header (plus a doc comment quoting a full one, describing the bug that alternative fixes). The siblings' verbatim pattern is a guaranteed false positive on every release — verified against the 0.1.0 tarball. Excluding that one module keeps the check meaningful for the other 92 files, and a second, narrower scan still runs across everything including the excluded module, so a real token-shaped leak there still fails. mcp/miner depend on contract exactly as they depend on engine, so the reconciliation job now treats both as prerequisites: contract and engine publish first, and mcp/miner are skipped entirely if either fails, rather than resolving a dependency version that exists nowhere and failing ETARGET. Contract stays independently versioned (like ui-kit) rather than joining the engine-and-dependents linked-versions group: it has only just shipped 0.1.0, and renumbering it into the 3.x train before it has any consumers costs more than it buys. Revisit at its next major. Also adds the LICENSE file the package declares (AGPL-3.0-only) but never shipped — engine, mcp and ui-kit all carry one. Closes #9749 * fix(release): put contract in the linked-versions group, not on ui-kit's independent cadence Review catch on #9753: contract was left out of the "engine-and-dependents" linked-versions group on the reasoning that it should version independently "like ui-kit". That reasoning was wrong, and this repo has already paid for the bug it reintroduces. mcp-release-please.yml's own header is explicit about what the group is for: mcp/miner carry a REAL runtime `dependencies` entry, so node-workspace bumps their range the moment the prerequisite's version changes -- and under separate-pull-requests: true that bump lands on the dependent's OWN branch, leaving its package.json requiring a version that exists nowhere (not locally, since the prerequisite's bump is on a different unmerged branch; not on npm, since it hasn't published). `npm ci` then fails ETARGET. That was confirmed live across several release cycles (#7086/#7087/#7107/#7108/#7119/#7120/#7121), and node-workspace's own `merge` option was already tried and does NOT override separate-pull-requests. ui-kit is outside the group because it has NO dependency edge to anything here -- not because independent versioning is the default. contract has exactly the edge engine has, so it belongs in the group for exactly the same reason. Membership tracks the dependency edge, not release cadence; the header now says so, since "publish it like ui-kit" is the trap that produced this. The reconciliation ordering added in this PR stays: the group fixes the release-PR stage (ranges and versions land in one commit), reconciliation fixes the publish stage (registry propagation and dispatch ordering). Engine needs both today and contract needs both for the same reasons. Cost of the fix, stated plainly: contract joins the group's version train rather than staying at 0.1.0, so its next release will not be 0.2.0. That is a worse version story than independence and a better correctness story, and 0.1.0 is already published either way. * ci(release): derive linked-versions membership from the real dependency graph Adding contract to the group fixed today's instance. It did not fix the class: group membership is a function of the dependency graph, nothing enforced that, and the last time an edge was added the config was not updated. #9521 made @loopover/contract a runtime dependency of both @loopover/mcp and @loopover/miner without touching linked-versions, and that sat unnoticed until #9749 -- by which point the package was not even published, so the next mcp/miner release would have shipped uninstallable. check-release-linked-versions.ts derives the requirement instead of trusting memory. It reads the real package.json edges between release-please-tracked packages and fails when two are joined by a shipping dependency but not by a linked-versions group -- the exact ETARGET race mcp-release-please.yml's header documents, and which node-workspace's own `merge` option provably does not fix. It also closes a second silent gap found while wiring this: sync-release-manifest builds its work list from the MANIFEST's own keys (`if (!(workspacePath in manifest)) continue`), so a package added to release-please-config.json but not to the manifest is silently exempt from the staleness check that stops release-please re-proposing an already-published version. Adding a package to one file and not the other had no feedback at all; now it fails. Deliberately scoped to dependencies/peerDependencies/optionalDependencies. devDependencies are excluded because they never reach a consumer, and forcing two packages into permanent version lockstep over a build-time-only edge costs more than the failure it prevents -- which surfaces immediately in CI on the branch that introduced it rather than in a published artifact. That tradeoff is written down at the constant, so the next person hitting it can revisit deliberately. ui-kit is the case that proves the check is not merely "group everything": it has no dependency edge, stays ungrouped, and there is an invariant test asserting it is never reported -- otherwise the check would drag unrelated packages into lockstep, which is the opposite of the goal. Verified both ways: removing contract from the group reproduces the #9521 gap and exits 1 naming both offending edges; removing its manifest entry exits 1 naming the consequence; the real config exits 0.
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.
🤖 I have created a release beep boop
3.1.1 (2026-07-17)
Fixes
Dependencies
This PR was generated with Release Please. See documentation.