Skip to content

release: adopt package.json semver as canonical version#208

Open
benvinegar wants to merge 2 commits intomainfrom
feat/semver-releases-package-version
Open

release: adopt package.json semver as canonical version#208
benvinegar wants to merge 2 commits intomainfrom
feat/semver-releases-package-version

Conversation

@benvinegar
Copy link
Copy Markdown
Member

Summary

  • make package.json.version the canonical Baudbot product version
  • stamp semver metadata into release snapshots and deployed runtime metadata while preserving SHA provenance
  • switch release automation from LLM-based bump decisions to explicit PR labels for patch, minor, or none
  • add release documentation and regression coverage for the new version helpers and metadata flow

Testing

  • npm test
  • npm run lint
  • npm run typecheck

This PR description was generated by Pi using GPT-5 Codex

@greptile-apps
Copy link
Copy Markdown

greptile-apps Bot commented May 5, 2026

Greptile Summary

This PR makes package.json.version the canonical Baudbot semver, stamps it into both baudbot-release.json and baudbot-version.json, and replaces the Claude-LLM bump decision with a deterministic label-based system (release:minor, release:patch, release:none). The shell helper abstraction in version-common.sh is clean and the regression tests cover the new helpers.

Confidence Score: 4/5

Safe 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

Filename Overview
.github/workflows/release-on-main.yml Removes Claude-LLM-based bump decision; replaces it with label-driven jq logic. Orphaned pr_context_capped.json generation is dead code after the refactor.
bin/lib/version-common.sh New helper exporting bb_package_version, bb_package_version_or_unknown, and bb_release_tag_for_version. Has an implicit dependency on json_get_string from json-common.sh that is not documented.
bin/baudbot Sources version-common.sh and delegates version() to it; old inline fallback becomes unreachable dead code in any intact installation.
bin/deploy.sh Stamps version and tag into baudbot-version.json; edge case where version is "unknown" produces "tag": "vunknown" in the JSON metadata.
bin/update-release.sh Adds version and tag fields to baudbot-release.json via bb_package_version_or_unknown; straightforward and correct.
bin/lib/baudbot-runtime.sh Updates print_deployed_version to read and display new version and tag fields from baudbot-version.json; logic looks correct.
bin/lib/release-runtime-common.sh Enriches the verified-deployment log line with the semver version when available; no logic issues.
bin/lib/version-common.test.sh New test file with two passing unit tests covering bb_package_version and bb_release_tag_for_version; consistent with existing test patterns.
bin/update-release.test.sh Adds regression checks for version and tag fields in the release JSON; correctly validates the new fields.
.github/release-labeler.yml New file defining the three release labels (release:minor, release:patch, release:none); straightforward configuration.
docs/releases.md New documentation file accurately describing semver policy, release model, and automation flow.

Sequence Diagram

sequenceDiagram
    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
Loading

Comments Outside Diff (2)

  1. .github/workflows/release-on-main.yml, line 90-93 (link)

    P2 The pr_context_capped.json artifact is still generated here but no longer consumed anywhere in the workflow. After the Claude LLM step was removed, the decide step now reads from /tmp/pr_context.json directly. This line is dead code and produces an unused file on every run.

    Prompt To Fix With AI
    This is a comment left during a code review.
    Path: .github/workflows/release-on-main.yml
    Line: 90-93
    
    Comment:
    The `pr_context_capped.json` artifact is still generated here but no longer consumed anywhere in the workflow. After the Claude LLM step was removed, the `decide` step now reads from `/tmp/pr_context.json` directly. This line is dead code and produces an unused file on every run.
    
    
    
    How can I resolve this? If you propose a fix, please make it concise.
  2. bin/baudbot, line 77-91 (link)

    P2 Fallback code in version() is unreachable in practice

    VERSION_COMMON_HELPER is always assigned a non-empty path at line 44, and in any intact installation version-common.sh will exist, so the [ -f "$VERSION_COMMON_HELPER" ] guard always evaluates to true. The legacy json_get_string_or_empty fallback below it is dead code. If the intent is robustness against a missing helper file, a short inline comment explaining that would help future readers understand why the old code is kept.

    Prompt To Fix With AI
    This is a comment left during a code review.
    Path: bin/baudbot
    Line: 77-91
    
    Comment:
    **Fallback code in `version()` is unreachable in practice**
    
    `VERSION_COMMON_HELPER` is always assigned a non-empty path at line 44, and in any intact installation `version-common.sh` will exist, so the `[ -f "$VERSION_COMMON_HELPER" ]` guard always evaluates to true. The legacy `json_get_string_or_empty` fallback below it is dead code. If the intent is robustness against a missing helper file, a short inline comment explaining that would help future readers understand why the old code is kept.
    
    How can I resolve this? If you propose a fix, please make it concise.
Prompt To Fix All With AI
Fix the following 4 code review issues. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 4
.github/workflows/release-on-main.yml:90-93
The `pr_context_capped.json` artifact is still generated here but no longer consumed anywhere in the workflow. After the Claude LLM step was removed, the `decide` step now reads from `/tmp/pr_context.json` directly. This line is dead code and produces an unused file on every run.

```suggestion
          echo "has_changes=true" >> "$GITHUB_OUTPUT"
```

### Issue 2 of 4
bin/baudbot:77-91
**Fallback code in `version()` is unreachable in practice**

`VERSION_COMMON_HELPER` is always assigned a non-empty path at line 44, and in any intact installation `version-common.sh` will exist, so the `[ -f "$VERSION_COMMON_HELPER" ]` guard always evaluates to true. The legacy `json_get_string_or_empty` fallback below it is dead code. If the intent is robustness against a missing helper file, a short inline comment explaining that would help future readers understand why the old code is kept.

### Issue 3 of 4
bin/lib/version-common.sh:14-22
**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.

### Issue 4 of 4
bin/deploy.sh:449-462
**`"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.

Reviews (1): Last reviewed commit: "release: automate semver bumps from PR l..." | Re-trigger Greptile

Comment thread bin/lib/version-common.sh
Comment on lines +14 to +22
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"
}
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 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.

Comment thread bin/deploy.sh
Comment on lines 449 to 462
@@ -449,7 +461,7 @@ if [ "$DRY_RUN" -eq 0 ]; then
}
VEOF
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 "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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant