post-release-vcpkg: fix version source, simplify UX, add no-secrets CI notification#89
Conversation
- Verify original TA-Lib repo (not a fork) before --perform-local-changes/--create-pr - Verify on 'main' branch before creating PRs - Check for existing open PR in microsoft/vcpkg before creating a duplicate - Improve version-mismatch error message to mention draft/unpublished releases - Add .github/workflows/post-release-vcpkg.yml: triggers on release.published, runs the script in plan mode, posts SHA512 + instructions as job summary (no PAT or secret required)
- Use word-boundary regex in _check_no_existing_vcpkg_pr to avoid false positives (e.g. 0.6.1 matching 0.6.10) - Add permissions: contents: read to the GitHub Actions workflow job to satisfy GITHUB_TOKEN least-privilege requirement
…ct CI ref Concern 1 - workflow value: - Workflow still fires on release.published as a reminder and pre-computes SHA512 in CI (useful for multi-person teams / async coordination) - --plan flag added for non-interactive CI mode Concern 2 - version source: - Authoritative version now comes from the GitHub releases/latest API (not local VERSION file), so running after main has been bumped works - Local VERSION used as informational cross-check only (prints [info] if different, never errors) - Workflow changed to checkout release tag not main, so VERSION always matches the published release in CI too - read_latest_release_src_tarball() also checks draft=true and rejects it Concern 3 - UX and idempotency: - Default (no flags) = full pipeline; no lengthy flags needed - Interactive confirmation prompt before any side-effects - --plan flag for non-interactive/CI mode - Removed --perform-local-changes and --create-pr - 'no changes to commit' guard improved with clearer message - Existing PR duplicate-check still present
|
|
||
| # Cross-check with local VERSION — warn if they differ (main may be bumped ahead). | ||
| try: | ||
| local_version = read_local_version() |
There was a problem hiding this comment.
You are building from the tarball, so this is more like a sanity test that the user local branch matches (and was not confuse testing something else). Wondering, should it be done comparing release tag (hash) instead of just VERSION. When it fails, make sure you give instruction about how to get the local repos on the needed tag with git (and give optional instruction to the user about how to go back to latest AFTER done with this operation).
There was a problem hiding this comment.
Replaced the VERSION-file comparison with a git-tag-hash check. read_latest_release_src_tarball now also returns the tag_name from the GitHub release API. _check_local_at_release_tag resolves that tag locally via git rev-parse refs/tags/<tag>^{} and compares it against HEAD. On mismatch it prints:
[info] Local HEAD (abc123456789) does not match release tag 'v0.6.4' (def098765432).
[info] The vcpkg update will still use the downloaded tarball for version 0.6.4,
[info] but if you want your local checkout to match the release:
[info] git checkout v0.6.4
[info] (To return to the latest main afterwards: git checkout main)
If the tag isn't present locally at all it suggests git fetch --tags first.
mario4tier
left a comment
mario4tier
left a comment
There was a problem hiding this comment.
Check the inline comments, fix the code.
…ash for local sanity check
|
Important, do not submit PR to main. You can submit changes only into dev. The maintainer (myself) will merge into main later. |
mario4tier
left a comment
mario4tier
left a comment
There was a problem hiding this comment.
Approved, but you have to rebase to commit into dev, not main.
|
AI agent: you have to rebase to the dev branch. No changes go to main directly, have to always soak in dev for a while first. |
Three bugs/design issues in the vcpkg post-release workflow: version was read from the local
VERSIONfile (broken whenmainis bumped past the release), the CI workflow checked outmaininstead of the release tag (same root cause), and the manual step required memorizing two verbose flags.Version source (concern 2)
releases/latestGitHub API. LocalVERSIONis a cross-check only — mismatch prints[info]and continues with the release version instead of erroring.ref: main→ref: ${{ github.event.release.tag_name }}, so the CI checkout always matches the published release.read_latest_release_src_tarball()now explicitly rejectsdraft: truereleases.UX — no flags needed (concern 3)
Default invocation does everything; confirmation prompt guards against accidents (matches
post-release-brew.pypattern):Removed
--perform-local-changesand--create-pr. Added--planfor non-interactive/CI use.Idempotency (concern 3)
Safe to run multiple times for the same release:
git checkout -B ta-lib-{version}and the "no changes to commit" guard prevent duplicate commits.CI workflow value (concern 1)
Workflow fires on
release.publishedas a reminder and pre-computes SHA512 — useful for async coordination when the person publishing the release isn't the one submitting the vcpkg PR. Zero secrets required; the "Next Step" in the job summary is the single no-flag command above.