chore(release): cut engine v3.2.1 - #7119
Closed
JSONbored wants to merge 3 commits into
Closed
Conversation
Deploying with
|
| Status | Name | Latest Commit | Updated (UTC) |
|---|---|---|---|
| 🔵 In progress View logs |
loopover-ui | 804e9fd | Jul 17 2026, 10:05 PM |
Contributor
|
Superagent didn't find any vulnerabilities or security issues in this PR. |
Owner
Author
|
Superseded -- node-workspace's own merge:true (#7114) wasn't sufficient on its own; separate-pull-requests also needs to be false for release-please's cross-component Merge plugin to actually combine these. Closing to verify the follow-up fix. |
loopover-orb
Bot
added
the
gittensor:bug
2 tasks
Bundle ReportBundle size has no change ✅ Affected Assets, Files, and Routes:view changes for bundle: loopover-uiAssets Changed:
|
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #7119 +/- ##
==========================================
+ Coverage 93.75% 95.98% +2.22%
==========================================
Files 692 609 -83
Lines 68809 48153 -20656
Branches 18781 15133 -3648
==========================================
- Hits 64512 46218 -18294
+ Misses 3302 1118 -2184
+ Partials 995 817 -178
Flags with carried forward coverage won't be shown. Click here to find out more. |
galuis116
pushed a commit
to galuis116/gittensory
that referenced
this pull request
Jul 18, 2026
JSONbored#7114's node-workspace merge:true was insufficient -- verified against release-please's own manifest.ts and docs/manifest-releaser.md that separate-pull-requests: true is enforced as the final PR-splitting decision regardless of what a plugin like node-workspace attempts internally, so mcp/miner's Release PRs kept landing separately from engine's even with that flag set (confirmed live: JSONbored#7119/JSONbored#7120/JSONbored#7121 still required an unpublished @loopover/engine version each). linked-versions is release-please's actual mechanism for overriding per-component isolation for a named subset: {engine, mcp, miner} now release as one PR/commit whenever any of them needs a release, since mcp and miner both carry a real runtime dependency on engine. ui-kit has no dependency edge to any of them and is not in the group, so it keeps its fully independent cadence.
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.2.1 (2026-07-17)
Fixes
This PR was generated with Release Please. See documentation.