Put releases back on merges to main#467
Merged
Merged
Conversation
Restores the guard 7ddac38 replaced with `if: false`, so merging to main bumps the patch version, uploads to PyPI with the existing PYPI_API_TOKEN secret, and pushes the bump commit plus its tag. The guard matters: the same workflow also fires on pull requests and a nightly schedule, and an unguarded job would cut a release from both. release.yml keeps building, smoke-testing and attesting every v* tag — only its upload is switched off, so the tag stable.yml pushes cannot start a second upload of a version PyPI already has. Going back to tag-driven releases means registering a PyPI trusted publisher for release.yml and swapping the two conditions.
|
Up to standards ✅🟢 Issues
|
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
1 participant
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.
Reverts the release trigger to the pre-#455 rhythm: merge to
main→ publish.stable.yml's publish job gets its original guard back (github.event_name == 'push' && github.ref == 'refs/heads/main'), exactly as it read before 7ddac38 disabled it. The guard is load-bearing — the workflow also runs onpull_requestand a nightlyschedule, so an unguarded job would cut a release from every PR and every night.PYPI_API_TOKENsecret is still present (updated 2026-04-21) and the job uploads with twine, so this does not depend on the PyPI trusted-publisher registration thatv0.0.215failed on.release.yml's upload is switched off so the tagstable.ymlpushes cannot start a second upload of a version PyPI already has. Itsbuildjob still runs on everyv*tag: verify tag matches pyproject, smoke-test the wheel, attest provenance.What happens when this reaches
main: the publish job fires on the merge, bumps0.0.215→0.0.216, uploads to PyPI, pushes the bump commit ([skip ci]) and tagv0.0.216, and creates the GitHub Release. That published version carriespillow==12.3.0, which is what closes the 13 open Dependabot alerts.The unused
v0.0.215tag is deleted separately — nothing was ever published under it, and the auto-bump will producev0.0.216.