release: adopt package.json semver as canonical version#208
release: adopt package.json semver as canonical version#208benvinegar wants to merge 2 commits intomainfrom
Conversation
Greptile SummaryThis PR makes Confidence Score: 4/5Safe to merge; all findings are P2 quality/style issues with no runtime correctness impact on the happy path. No P0 or P1 defects found. Four P2 findings: orphaned dead code in the workflow, unreachable fallback in version(), undocumented cross-file dependency in version-common.sh, and a cosmetic vunknown tag written in edge-case metadata. None affect correctness on the normal release path. .github/workflows/release-on-main.yml (orphaned capped-PR file generation), bin/deploy.sh (vunknown tag edge case). Important Files Changed
Sequence DiagramsequenceDiagram
participant GH as GitHub Push (main)
participant WF as release-on-main.yml
participant PKG as package.json
participant PRS as Merged PRs API
participant REPO as Git Repo
GH->>WF: push to main
WF->>REPO: git fetch --tags
WF->>PKG: read current_version
WF->>PRS: gh api /pulls (merged since last tag)
PRS-->>WF: /tmp/pr_context.json
WF->>WF: jq label decision
Note over WF: release:minor → minor<br/>release:patch → patch<br/>all release:none → none<br/>else → patch
alt decision == patch or minor
WF->>PKG: bump version (node)
WF->>REPO: git commit + tag vX.Y.Z
WF->>GH: push --atomic origin main + tag
WF->>GH: gh release create vX.Y.Z
else decision == none
WF->>WF: no-op summary
end
|
| bb_package_version() { | ||
| local root="${1:?repo root required}" | ||
| local package_json="" | ||
|
|
||
| package_json="$(bb_package_json_path "$root")" | ||
| [ -r "$package_json" ] || return 1 | ||
|
|
||
| json_get_string "$package_json" "version" | ||
| } |
There was a problem hiding this comment.
Undocumented dependency on
json_get_string from json-common.sh
bb_package_version calls json_get_string, which is defined in bin/lib/json-common.sh and not in this file. All current callers (deploy.sh, update-release.sh, baudbot, the test file) correctly source json-common.sh first, but there is no declaration of this requirement in version-common.sh itself. A sourcing guard or a comment at the top noting the prerequisite would prevent subtle breakage if this helper is ever sourced in a new context without the dependency.
Prompt To Fix With AI
This is a comment left during a code review.
Path: bin/lib/version-common.sh
Line: 14-22
Comment:
**Undocumented dependency on `json_get_string` from `json-common.sh`**
`bb_package_version` calls `json_get_string`, which is defined in `bin/lib/json-common.sh` and not in this file. All current callers (`deploy.sh`, `update-release.sh`, `baudbot`, the test file) correctly source `json-common.sh` first, but there is no declaration of this requirement in `version-common.sh` itself. A sourcing guard or a comment at the top noting the prerequisite would prevent subtle breakage if this helper is ever sourced in a new context without the dependency.
How can I resolve this? If you propose a fix, please make it concise.| @@ -449,7 +461,7 @@ if [ "$DRY_RUN" -eq 0 ]; then | |||
| } | |||
| VEOF | |||
There was a problem hiding this comment.
"vunknown" written into metadata JSON when version is unavailable
When neither the git repo nor an existing $RELEASE_META_FILE provides a version (e.g., a freshly checked-out archive with no package.json), RELEASE_VERSION is set to "unknown". The subsequent bb_release_tag_for_version "unknown" call then writes "tag": "vunknown" into baudbot-version.json. Tools or operators parsing the tag field for semver validity would receive an unexpected value. Guarding the bb_release_tag_for_version call to only run when RELEASE_VERSION is not "unknown" would be more consistent.
Prompt To Fix With AI
This is a comment left during a code review.
Path: bin/deploy.sh
Line: 449-462
Comment:
**`"vunknown"` written into metadata JSON when version is unavailable**
When neither the git repo nor an existing `$RELEASE_META_FILE` provides a version (e.g., a freshly checked-out archive with no `package.json`), `RELEASE_VERSION` is set to `"unknown"`. The subsequent `bb_release_tag_for_version "unknown"` call then writes `"tag": "vunknown"` into `baudbot-version.json`. Tools or operators parsing the tag field for semver validity would receive an unexpected value. Guarding the `bb_release_tag_for_version` call to only run when `RELEASE_VERSION` is not `"unknown"` would be more consistent.
How can I resolve this? If you propose a fix, please make it concise.
Summary
package.json.versionthe canonical Baudbot product versionpatch,minor, ornoneTesting
This PR description was generated by Pi using GPT-5 Codex