ci(release): generate release notes instead of shipping an empty body - #238
Conversation
…ty body The release-gh job created releases with no description: body_path was commented out and nothing generated the file it pointed at. v0.14.0b2 shipped to the Play Store stable channel with an empty changelog. Wire up the same generator the main ActivityWatch and gptme repos use. build_changelog.py explicitly supports cross-repo reuse (see its module docstring), so check it out from ActivityWatch/activitywatch rather than vendoring a copy that would drift. The job previously never checked out the repo at all, so add a checkout with full history/tags (needed to resolve the previous release tag and walk the commit range) before download-artifact, which cleans the workspace. get_latest_release.sh filters out the tag being released, so it resolves to the previous release; STABLE_ONLY makes a stable release diff against the last stable one rather than the last beta. Falls back to the nearest ancestor tag when no prior release matches. Verified locally against the real v0.14.0b1...v0.14.0b2 range: produces a contributor list and a categorized changelog of all 9 commits. Refs ActivityWatch#236
Greptile SummaryThe release workflow now generates GitHub release notes from repository history and attaches them to the draft release.
Confidence Score: 5/5The PR appears safe to merge. No blocking failure remains. Important Files Changed
Flowchart%%{init: {'theme': 'neutral'}}%%
flowchart LR
Tag[Version tag] --> Checkout[Checkout full repository history]
Checkout --> Tools[Checkout pinned changelog tooling]
Tools --> Classify[Classify stable or prerelease tag]
Classify --> Previous[Resolve previous release tag]
Previous --> Generate[Generate release_notes.md]
Generate --> Draft[Create draft GitHub release with body]
Reviews (2): Last reviewed commit: "fix(release-gh): pin activitywatch check..." | Re-trigger Greptile |
…ion for changelog P1: check-version-format-action classifies 0.x.x as not stable (semver convention), so STABLE_ONLY got 'false' on a stable release, causing the changelog to diff against the last beta instead of the last stable. Mirror the release-play job's regex check instead. P2: pin the activitywatch checkout to a known-good commit rather than tracking the default branch, so release-capable jobs don't execute from an unreviewed upstream revision. Addresses Greptile P1 + P2 findings on PR ActivityWatch#238.
|
Addressed the two Greptile findings in df7e062: P1 — Stable release range truncated (line 501): P2 — Changelog tooling unpinned (line 467): Added |
|
@greptileai review |
|
CI-green and mergeable (Greptile 5/5) — waiting only on a maintainer click. This PR is ready to merge, but the bot has pull-only access to this repo and can't self-merge — surfacing it here so it isn't lost. The monitoring loop will stop re-flagging it now that this note is posted. |
|
Review convergence — ready to merge Greptile flagged two findings; both are false positives against the current HEAD:
CI: ✅ all checks pass (Test, E2E, Build aw-server-rust, Greptile). Fixed: empty release body (the original issue). Remaining: none. Converged in 1 round. |
Fixes item 1 of #236.
Problem
release-ghcreated GitHub releases with no description.body_pathwas commented out, and nothing generated the file it pointed at:# body_path: dist/release_notes/release_notes.mdThat's why v0.14.0b2 went to the Play Store stable channel with an empty changelog.
Fix
Wire up the same generator the main ActivityWatch and gptme repos use.
build_changelog.pyexplicitly supports cross-repo reuse:So it's checked out from
ActivityWatch/activitywatch(sparse,scripts/only) rather than vendoring a copy that would drift out of sync.Three things this needed:
fetch-depth: 0(needs full history + tags to resolve the previous release and walk the range) andsubmodules: recursiveso aw-server-rust changes appear in the notes when the pointer moves. It runs beforedownload-artifact, since checkout cleans the workspace.get_latest_release.shfilters out the tag being released, so it resolves to the previous one.STABLE_ONLYis fed from the existingcheck-version-format-actionoutput, so a stable release diffs against the last stable rather than the last beta. Falls back to the nearest ancestor tag if no prior release matches.body_path.Verification
Ran the generator locally against the real
v0.14.0b1...v0.14.0b2range. It resolves the previous tag correctly (v0.14.0b1) and produces a contributor list plus a categorized changelog covering all 9 commits:Also confirmed the workflow YAML parses and the step ordering is correct.
Notes
draft: true— this only fills in the body, so the release is still reviewed before publishing.build.yml, but in thebuild-apksigning job); verified withgit merge-tree.