feat(release): extend the release-due watcher + tarball pack-check to engine/miner/ui-kit#8592
Merged
Conversation
… engine/miner/ui-kit (#8591) Only MCP had a "release due" tracking-issue safety net (mcp-release-watch.yml) and a published-tarball dry-run validator (test:mcp-pack) -- engine, miner, and ui-kit had neither. If release-please ever silently stopped proposing a release PR for one of them, nothing would flag it, and their published npm tarballs were never checked for stray/forbidden/secret-like content. - scripts/release-semver-utils.ts: pure semver/conventional-commit primitives extracted from mcp-release-core.ts (parseConventionalSubject, compareSemver, bumpVersion, latestSemverTagWithPrefix, inferReleaseTypeFromSubjects, escapeIssueMarkdownText, shortSha) so both MCP's bespoke watcher and the new generic one share one implementation instead of duplicating it. MCP's own public API is unchanged (same exports, same behavior -- verified against its full existing test suite, 105 tests across 8 files, zero regressions). - scripts/package-release-core.ts: the generic due-detection/issue-building core for engine/miner/ui-kit. Deliberately simpler than MCP's: none of the three have commits needing cross-cutting-path attribution the way MCP wraps app-side Worker logic, and all three already have release-please maintaining their CHANGELOG.md natively (release-please-config.json), so no bespoke changelog renderer is needed here. - scripts/check-package-release-due.ts: generic upsert/close CLI, parameterized by --package engine|miner|ui-kit, mirroring check-mcp-release-due.ts (including the #6145 auto-close-once-caught-up fix). - .github/workflows/package-release-watch.yml: ONE new job checking all three packages sequentially (not a matrix) -- the shared Actions runner pool is org-wide, and #8574's investigation found extra concurrent scheduled-run runners a direct contributor to queue saturation, so this adds zero additional concurrent runner load. - scripts/check-engine-package.ts / check-ui-kit-package.ts: npm-pack dry-run validators (test:engine-pack / test:ui-kit-pack, wired into test:ci and ci.yml). Pattern-based allowlists (^dist/.*\.(js|d\.ts)$ etc.), not enumerated file lists like MCP/miner's small hand-curated ones -- engine ships 358 files and ui-kit 152, mirroring their src/ trees 1:1 via tsc's default output shape, and will keep growing as the engine extraction continues (per its own README). Also fixes two real gaps the new ui-kit pack-check immediately caught: ui-kit's CHANGELOG.md existed on disk but was missing from package.json's "files" field (silently excluded from the published npm tarball), and ui-kit had no README.md at all. Both fixed.
Deploying with
|
| Status | Name | Latest Commit | Updated (UTC) |
|---|---|---|---|
| ❌ Deployment failed View logs |
loopover-ui | 730d805 | Jul 24 2026, 11:41 PM |
Contributor
|
Superagent didn't find any vulnerabilities or security issues in this PR. |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #8592 +/- ##
=======================================
Coverage 92.54% 92.54%
=======================================
Files 796 796
Lines 79850 79850
Branches 24135 24135
=======================================
Hits 73899 73899
Misses 4802 4802
Partials 1149 1149
Flags with carried forward coverage won't be shown. Click here to find out more. |
Bundle ReportBundle size has no change ✅ |
loopover-orb
Bot
added
the
gittensor:bug
Contributor
|
Warning ⏸️ LoopOver review result - manual review recommendedReview updated: 2026-07-25 00:26:58 UTC
Review summary Nits — 7 non-blocking
Decision drivers
Context & advisory signals — never blocks the verdict
Linked issue satisfactionAddressed 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. 🟩 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.
|
test/unit/check-ui-kit-package.test.ts's real-package regression test needs packages/loopover-ui-kit/dist/ on disk, but validate-tests never built ui-kit -- only validate-code did, in a separate job/runner. This job runs the general test/unit/*.test.ts suite unconditionally whenever it runs at all, so the test failed on CI (confirmed live on #8592) even though it passed locally where ui-kit had already been built manually. Reproduced locally by deleting packages/loopover-ui-kit/dist/ and confirming npm run test:ui-kit-pack fails exactly as CI reported, then confirming the new Build UI-kit package step (mirroring engine/MCP/ miner's existing pattern in this same job) fixes it.
This was referenced Jul 25, 2026
JSONbored
added a commit
that referenced
this pull request
Jul 25, 2026
* fix(deps): resolve postcss + tar audit findings via overrides npm audit flagged postcss <=8.5.17 (path traversal in previous-sourcemap auto-loading, GHSA-r28c-9q8g-f849, high) and tar <=7.5.20 (uncontrolled recursion DoS via crafted long-path tar, GHSA-r292-9mhp-454m, moderate), both transitive. Pin both via overrides, matching this file's existing pattern for other transitive-dep security fixes: bump the existing tar override past its first-patched version (7.5.19 -> 7.5.21) and add a new postcss override (8.5.18, first patched version). Closes task 1 of #8588's checklist. The remaining findings in that issue (eslint v10 bump for the brace-expansion/minimatch chain, the @esbuild-kit->tsx trace, and the recharts v3 migration) are unrelated, each need their own scoping, and are now tracked as sub-issues #8608, #8609, #8610. * build: add the missing ui-kit build step to the local test:ci gate Discovered incidentally while running the full local gate for #8588: test/unit/check-ui-kit-package.test.ts's own regression guard needs packages/loopover-ui-kit/dist/ to exist, but the root test:ci script never built that workspace before test:coverage -- unlike the real CI validate-tests job, which already builds it via `npx turbo run build --filter=@loopover/ui-kit` right before its own coverage step (added in #8592 to close this exact gap, but only in the CI workflow, not the local script this repo's own contributing guide points everyone at). Anyone running `npm run test:ci` from a clean checkout hit a spurious failure that real CI never showed. Adds `npm run build --workspace @loopover/ui-kit` alongside the other per-package builds already in the chain (engine, discovery-index, mcp, miner), so the local script matches CI again. * fix(mcp): stop CLI stdout truncation on >64KB piped output Discovered incidentally while running the full local gate for #8588: test/unit/mcp-cli-profiles.test.ts's changelog test started failing with a JSON parse error once packages/loopover-mcp/CHANGELOG.md grew past the OS pipe buffer size (verified: `loopover-mcp changelog --json | wc -c` returned exactly 65536 bytes instead of the real 65603+ -- the classic 64KB pipe-buffer boundary). Root cause: process.stdout/stderr writes to a POSIX pipe are asynchronous, but the CLI entrypoint called process.exit() immediately after the command's async work resolved, cutting off any pending write larger than one pipe buffer's worth before it finished flushing. This silently truncates any command's output over ~64KB for any real consumer piping the CLI (not just this test) -- e.g. `loopover-mcp changelog --json | jq` would get invalid JSON. Fix: drain both streams (wait for their internal buffer to empty) right before calling process.exit(), instead of changing when/whether process.exit() itself is called -- keeps the existing fast-exit behavior for everything else (no risk of hanging on a lingering fetch keep-alive socket) while fixing the truncation at its actual source. * test(miner): raise timeout for build:verify syntax-check regression guard Discovered incidentally while running the full local gate for #8588: this test spawns a real subprocess (node --check over every dist/bin+dist/lib file in packages/loopover-miner) -- 5.5s in isolation, but it exceeded the default 15s testTimeout once under the full suite's parallel load. Genuinely necessary real subprocess work with no redundancy to cut, matching this repo's established real-subprocess timeout-flake pattern (agent-sdk-driver.test.ts, miner-attempt-worktree .test.ts, miner-repo-clone.test.ts, #6869/#6871): raise to the same evidence-based 60000ms ceiling already used for that class of test, rather than reflexively widening without a reason.
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 #8591.
Summary
Only MCP had a "release due" tracking-issue safety net (
mcp-release-watch.yml) and a published-tarball dry-run validator (test:mcp-pack) — engine, miner, and ui-kit had neither. If release-please ever silently stopped proposing a release PR for one of them, nothing would flag it, and their published npm tarballs were never checked for stray/forbidden/secret-like content.scripts/release-semver-utils.ts: pure semver/conventional-commit primitives extracted frommcp-release-core.tsso both MCP's bespoke watcher and the new generic one share one implementation instead of duplicating it. MCP's own public API is unchanged (same exports, same behavior — verified against its full existing test suite, 105 tests across 8 files, zero regressions).scripts/package-release-core.ts: the generic due-detection/issue-building core for engine/miner/ui-kit. Deliberately simpler than MCP's — none of the three have commits needing cross-cutting-path attribution the way MCP wraps app-side Worker logic, and all three already have release-please maintaining theirCHANGELOG.mdnatively, so no bespoke changelog renderer is needed.scripts/check-package-release-due.ts: generic upsert/close CLI, parameterized by--package engine|miner|ui-kit, mirroringcheck-mcp-release-due.ts(including the MCP release due: 4.0.0 #6145 auto-close-once-caught-up fix)..github/workflows/package-release-watch.yml: one new job checking all three packages sequentially (not a matrix) — the shared Actions runner pool is org-wide, and Epic: consolidate the '-coverage' bolt-on test-file family #8574's investigation found extra concurrent scheduled-run runners a direct contributor to queue saturation, so this adds zero additional concurrent runner load.scripts/check-engine-package.ts/check-ui-kit-package.ts: npm-pack dry-run validators (test:engine-pack/test:ui-kit-pack, wired intotest:ciandci.yml). Pattern-based allowlists, not enumerated file lists like MCP/miner's small hand-curated ones — engine ships 358 files and ui-kit 152, mirroring theirsrc/trees 1:1, and will keep growing as the engine extraction continues.Bonus fix: the new ui-kit pack-check immediately caught two real gaps —
CHANGELOG.mdexisted on disk but was missing frompackage.json'sfilesfield (silently excluded from the published npm tarball), and ui-kit had noREADME.mdat all. Both fixed.Test plan
npx vitest run test/unit/generate-mcp-changelog-script.test.ts test/unit/mcp-release.test.ts test/unit/mcp-release-candidate.test.ts test/unit/package-release.test.ts test/unit/check-engine-package.test.ts test/unit/check-ui-kit-package.test.ts test/unit/check-mcp-package.test.ts test/unit/check-miner-package.test.ts— 105/105 passnpm run typecheck/npm run actionlint— cleannpm run test:engine-pack/npm run test:ui-kit-pack— pass against the real built packages (358 / 152 files)check-package-release-due.ts --package {engine,miner,ui-kit} --jsondirectly against real repo state to confirm end-to-end correctness