fix(ci): auto-generate GitHub release notes on publish - #43
Merged
Conversation
gh release create was passed --notes "", publishing every release with an empty body and requiring a manual gh release edit afterward (hit us on v1.5.2). Use --generate-notes so GitHub fills in notes from merged PRs since the previous tag.
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
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.
Intent
The developer wanted the PyPI publish GitHub Actions workflow for the python-tesla-fleet-api repo to auto-generate GitHub release notes instead of creating releases with an empty body, which had required manual editing after releases like v1.5.2. The specific requirement was a minimal change to the github-release job in .github/workflows/python-publish.yml, replacing the
gh release create --notes ""flag with--generate-notes, while leaving the rest of the job (dist upload, signing, permissions) untouched. Constraints included verifying the flag against gh's help, ensuring the workflow YAML remained valid, limiting the diff to only that one flag change, committing on a dedicated branch (fm/tfa-release-notes-w9) without pushing to the default branch, and validating/shipping the change through the no-mistakes pipeline to a PR with green CI. After the pipeline's push step initially failed due to a GitHub token lacking workflow scope, the developer refreshed the token and asked to retry the pipeline and report done with the PR URL once checks were green.What Changed
--notes ""flag with--generate-noteson thegh release createstep in thegithub-releasejob of.github/workflows/python-publish.yml, so PyPI publish releases are stamped with auto-generated "What's Changed" notes instead of an empty body that required manual editing (as happened for v1.5.2).Risk Assessment
✅ Low: Single-line CI workflow change swapping a verified-valid gh flag (--notes "" → --generate-notes) with required permissions already in place and no impact on the publish, signing, or upload steps.
Testing
Exercised the CI workflow change end-to-end without publishing anything: confirmed the diff is only the intended flag swap, validated the workflow YAML, verified --generate-notes against gh's help, executed the rendered release step against a stub gh to capture the exact command a tag push will run, and captured before/after product evidence — the production v1.5.2 run log showing the old empty-notes command versus a GitHub generate-notes API preview showing the auto-generated "What's Changed" body. No Python code changed, so the unit suite was not relevant; all checks passed.
Evidence: Simulated release step (rendered command + stub-gh argv)
Rendered step command: gh release create 'v1.5.2' --repo 'Teslemetry/python-tesla-fleet-api' --generate-notes stub-gh invoked as: argv[1]=release argv[2]=create argv[3]=v1.5.2 argv[4]=--repo argv[5]=Teslemetry/python-tesla-fleet-api argv[6]=--generate-notesEvidence: Before/after: old workflow's empty-notes command in production log vs generate-notes API preview
BEFORE (run 28638078573, tag v1.5.2): Run gh release create 'v1.5.2' --repo 'Teslemetry/python-tesla-fleet-api' --notes "" AFTER (generate-notes API preview, v1.5.1..v1.5.2 range): ## What's Changed * fix(proto): pin protobuf gencode to 6.32.0... (#40) * fix(vehicle): standardize auto seat climate on 1-indexed AutoSeat (#41) * feat(vehicle): add low power mode and keep accessory power signed commands (#42) Full Changelog: .../compare/v1.5.1...v1.5.2-notes-previewEvidence: Diff, YAML validation, and gh flag verification
Pipeline
Updates from git push no-mistakes
✅ **intent** - passed
✅ No issues found.
✅ **Rebase** - passed
✅ No issues found.
✅ **Review** - passed
✅ No issues found.
✅ **Test** - passed
✅ No issues found.
git diff 3b3ed0b..6bded01— confirmed the diff is exactly the one-flag change in .github/workflows/python-publish.ymlyaml.safe_load('.github/workflows/python-publish.yml')— workflow YAML parses; extracted the rendered release-step commandgh release create --help | grep generate-notes— confirmed the flag exists and is documentedExecuted the rendered stepgh release create 'v1.5.2' --repo 'Teslemetry/python-tesla-fleet-api' --generate-notesagainst a stubghcapturing exact argvgh run view 28638078573 --log— production log of the v1.5.2 tag run shows the OLD command--notes ""(release created empty, then manually edited), establishing the before stategh api repos/Teslemetry/python-tesla-fleet-api/releases/generate-notes(read-only preview) — produced the full "What's Changed" body with PR links that --generate-notes will stamp on future releases✅ **Document** - passed
✅ No issues found.
tesla_fleet_api/tesla/tesla.py- Pre-existing ruff format drift in 7 Python files (e.g. tesla_fleet_api/tesla/tesla.py, tesla_fleet_api/tessie/vehicles.py) untouched by this change; left as-is to keep the diff limited to the workflow flag change.✅ **Push** - passed
✅ No issues found.