Uh oh!
There was an error while loading. Please reload this page.
ci(release): match the existing vX.Y.Z tags, not a component prefix - #808
Conversation
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
AI Automated Review
Full PR review.
Analysis engine: MiniMax-M2.7@https://litellm.jory.dev/v1 (anthropic) — escalated (fast_low_confidence)
Review Summary
Recommendation: Approve
This is a targeted, well-documented fix to the release-please configuration that corrects how the release tooling identifies existing tags.
Change Analysis
File modified:release-please-config.json
The change adds two properties to the root package configuration under "packages": {".": {}}:
"include-component-in-tag": false"component": ""
What this fixes:
The release-type: node strategy derives a component from package.json's name field (which is "dispatch"), causing release-please to seek tags in the format dispatch-vX.Y.Z. However, the repository's actual tags follow the pattern vX.Y.Z. This mismatch meant:
- Release-please found no matching tags, leading it to walk the entire repository history (resulting in the 79KB changelog mentioned in PR 792)
- Incorrect version calculations due to ancient breaking changes being within range
What this enables:
- Matching existing
v0.5.38tags correctly - Computing changes over the actual 36 commits since the last release
- Proposing
0.5.39instead of incorrect major version bumps - Preserving the
v*tag series that downstream consumers (Helm chart, image tags, home-ops pin) depend on
Required Checks
| Check | Status | Notes |
|---|---|---|
| CI (all 7 checks) | ✅ Pass | Build, Lint, Coverage, Tests, Docker Build, Typecheck, npm audit all succeeded |
| Diff correctness | ✅ Pass | Added properties are valid release-please config options for the "node" release type |
| JSON validity | ✅ Pass | File read successfully; all CI checks passed (would fail on invalid JSON) |
| No linked issues | ✅ Pass | PR references PR 792 and PR 807 as context but no issue is linked to this PR |
Standards Compliance
This PR modifies release-please-config.json, a JSON configuration file for CI tooling. The AGENTS.md standards file applies primarily to TypeScript application code, Prisma schemas, and Docker configurations. No conflicting conventions are relevant to this change.
Tool Harness Findings
The tool harness verified:
- The file was read successfully and contains valid JSON
- Git log shows this is the third commit in the release configuration sequence (following PR 791 and PR 807)
- The commit is signed and verified
Unknowns / Needs Verification
- References to issues PR 792 and PR 807: The PR body references these as context for the problem being solved. While they are not formally linked to this PR, the problem description is self-contained and verifiable from the PR body alone.
- Impact on future releases: The configuration change will be validated when the next release is triggered. The change follows standard release-please configuration patterns and the logic is sound.
Conclusion
This is a correct, minimal fix that:
- Directly addresses the root cause of incorrect tag matching
- Uses documented release-please configuration options
- Has passed all CI checks
- Is well-documented in the PR description
- Does not affect any application code, database, or runtime behavior
Approve.
Summary
include-component-in-tag: falseandcomponent: ""on the root package.Why
release-type: nodederives a component frompackage.jsonname, which isdispatch, and prefixes tags with it. Release-please is therefore looking fordispatch-v0.5.38:Finding no matching tag, it concludes there has never been a release and walks the entire repository history. That is why #792's release notes are 79KB and carry Chores, Documentation, Refactors and CI sections going back to the beginning, rather than the 36 commits since v0.5.38.
It is also why #807 looked like it did nothing.
bump-patch-for-minor-pre-majorworked correctly and demoted the fivefeat:commits to a patch. The minor came from a breaking change in ancient history that is only in range because the range is wrong. There are no breaking markers in the real v0.5.38..main range.Effect
v0.5.38, computes over the 36 real commits, and with ci(release): keep feat commits on a patch bump below 1.0 #807 proposes 0.5.39.v*tag series stays intact, which matters because the Helm chart version, the image tag and the home-ops pin all follow it. Adispatch-v*series would orphan all three.Note
misospace/miso-chathas the same config shape (release-type: node, package namemiso-chat) and has already releasedmiso-chat-0.5.0while its tag series sits atv0.3.5. That one needs the same fix plus a decision about the already-published tag, and is not addressed here.