Repository navigation
Add tag-triggered release management to this repo - #38
Merged
Merged
Conversation
Follow-up to #37, which added release management to the generated project. This does the same for the outer cookiecutter-pyproject repo itself, with one difference: no PyPI publish. This repo is a cookiecutter template consumed via `cookiecutter gh:...`, not `pip install`, so a release here means a git tag and a GitHub release with the build artifacts attached, nothing more. - .github/workflows/release.yml triggers on `push: tags: [v*]`, verifies the tag matches the VERSION file via the new check-version.sh, runs the full test suite, builds the package, and creates a GitHub release. - release-tag.sh creates the annotated v<version> tag locally and prints the push command, keeping the push itself a deliberate action. - CHANGELOG.md gets a Keep a Changelog scaffold (was empty). - docs/development-instructions.md documents the bump -> merge -> tag flow, and docs/project-structure.md lists the new files. Verified locally: make check-style, check-types, test-unit, test-integration, test-e2e and build all pass, plus manual exercise of check-version.sh and release-tag.sh (matching/mismatched tag, clean/ dirty tree, existing tag). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
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.
Follow-up to #37
#37 added tag-triggered release management to the generated project. This does the same for the outer
cookiecutter-pyprojectrepo, with one deliberate difference: no PyPI publish. This repo is a cookiecutter template, consumed viacookiecutter gh:ali92hm/cookiecutter-pyproject, notpip install, so a release here is a git tag + GitHub release with the build artifacts attached — nothing gets uploaded to an index.What changed
.github/workflows/release.yml(new) — triggers onpush: tags: ['v*']. Verifies the tag matches theVERSIONfile, runsmake ci, builds the package, and creates a GitHub release viagh release create --generate-notes dist/*.scripts/check-version.sh(new) — asserts a given tag equalsv$(cat VERSION). Used by CI so a mismatch fails before anything is created.scripts/release-tag.sh(new) — creates the annotatedv<version>tag fromVERSION(refuses on a dirty tree or an existing tag) and prints the push command. The push stays a deliberate human action, same pattern as the generated project.Makefile— addscheck-versionandrelease-tagtargets.CHANGELOG.md— was empty; now has a Keep a Changelog scaffold with compare links.docs/development-instructions.md— documents the bump → merge → tag release flow.docs/project-structure.md— lists the new workflow and scripts.Testing
Run locally with real dependencies (Python 3.11):
make check-style— passmake check-types(mypy) — pass, 0 issuesmake test-unit— 16/16 passmake test-integration— 18/18 passmake test-e2e— 2/2 passmake build— succeedscheck-version.sh(matching tag / mismatched tag / no arg) andrelease-tag.sh(dirty tree / clean tree / existing tag) — all behaved correctly.release-tag.sh's success and existing-tag paths were tested against an isolated copy of the repo so as not to tag this real repo before a release is actually intended.release.ymlas YAML directly withruby -ryaml(no Jinja templating involved here, unlike the generated-project version)Known gap (shared with #37, not addressed here)
release.ymlaccepts av*tag pushed from any branch, so tagging a feature branch would trigger a release. Branch protection plus the documented tag-from-masterflow covers the normal case.🤖 Generated with Claude Code