Repository navigation
Tag each release commit with its pyproject.toml version - #4168
Merged
Merged
Conversation
Move .github/publish-git-tag.sh, unchanged, to .github/scripts/publish_git_tag.sh, where the ci-scripts guard runs shellcheck on it and requires a test for it, and run it with bash from the Publish Git Tag step. The new tests run the script in a clone whose origin is a bare repository. They fail: the script reads its version from setup.py, which no longer exists, so it pushes no release tag, pushes every local tag with git push --tags, and exits 0 when the version is missing or the tag names another commit. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
publish_git_tag.sh read the version from setup.py, which #3319 removed, ran a bare git tag when that failed, and hid every failure, so no release after 3.34.3 was tagged. It now reads [project] version from pyproject.toml with tomllib and requires a release version, looks the tag up on origin with git ls-remote, and passes when the tag already names the release commit (lightweight or annotated) so a rerun works. It fails when the tag names another commit. Otherwise it creates the tag on the release commit and pushes only that tag, under set -euo pipefail. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #4168 +/- ##
===========================================
+ Coverage 53.93% 88.30% +34.37%
===========================================
Files 281 293 +12
Lines 16261 17457 +1196
Branches 2629 2865 +236
===========================================
+ Hits 8770 15416 +6646
+ Misses 6760 1331 -5429
+ Partials 731 710 -21 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
This branch was previously deployed
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.
Fixes #4167
Summary
Release runs tag each release commit with its version again. The last tag the release run created is 3.34.3 (2026-02-24).
.github/scripts/publish_git_tag.sh(moved from.github/publish-git-tag.sh, so theci-scriptsguard now runs shellcheck on it and requires a test for it):[project] versionfrompyproject.tomlwithtomllib, and fails unless it's a release version (<major>.<minor>.<patch>). It used to runpython setup.py --version, andsetup.pywas removed in Migrate from setup.py to pyproject.toml #3319.originwithgit ls-remote. If the tag already names the release commit, lightweight or annotated, it changes nothing and passes, so a rerun of a release works. If it names another commit, it fails and names both commits.3.34.3), and pushes only that tag. It used to push every local tag withgit push --tags.set -euo pipefail, with no|| true.push.yml: the "Publish Git Tag" step runsbash .github/scripts/publish_git_tag.sh. The job is otherwise unchanged.docs/engineering/skills/ci-workflows.mddescribes what the step does.Expected effect
publish-git-tag. Every later release job needs it, so the release stops there instead of passing without a tag. Rerunning the job is safe once the cause is fixed.on: push: tagstrigger), so creating tags starts nothing else.The missing tags
The releases from 3.35.0 to the current version have no tags. Each "Update PolicyEngine API" commit records its version in
pyproject.toml(orsetup.py/policyengine_api/constants.pybefore #3319), so those tags could be created afterwards with a one-off script. This pull request creates none, and whether to do that is a separate decision.Testing
Built test-first:
962bf1aatests/unit/test_publish_git_tag_script.pyeda408a8The tests run the script in a temporary clone whose
originis a bare repository, with git's global and system configuration turned off. They cover: tagging the release commit with thepyproject.tomlversion; pushing only the release tag when another local tag exists; failing with no version and with a version that isn't a release version; failing, with the tag unchanged, when it names another commit; and passing, with the tag unchanged, when a lightweight or annotated tag already names the release commit. The two "already names" cases also passed before the fix, because the old script never created a tag.Ran only those tests, by node ID. Also ran:
shellcheckon the script,python scripts/run_quality_guards.py(every guard passed, includingci-scripts),python -m scripts.rules guard --base-ref origin/master,ruff format --checkandruff checkon the test file, andcheck_changelog_fragment.shagainstorigin/master.Environment variables and tokens
The script reads no environment variables of its own. What it uses:
GITHUB_TOKEN, whichactions/checkout@v4stores in the clone's git configuration (defaultpersist-credentials). Neitherpush.ymlnor thepublish-git-tagjob setspermissions, so the token has the repository's default workflow permissions,write(checked withgh api repos/PolicyEngine/policyengine-api/actions/permissions/workflow). The repository's only ruleset applies to branches, so nothing restricts creating tags.python3: fromactions/setup-python@v5(3.12) in the same job.tomllibneeds Python 3.11 or later.JOB_RESULTS: unchanged. It's set fromtoJSON(needs)for the precedingrelease_commit.py require-checksstep.🤖 Generated with Claude Code