Update publish workflow to handle release candidates#1391
Update publish workflow to handle release candidates#1391ReeceHumphreys wants to merge 3 commits into
Conversation
97dcc90 to
fc7e026
Compare
schaubh
left a comment
There was a problem hiding this comment.
I'm unclear what we are doing here? Could you please clarify the PR documentation? Is this for nightly builds? When would a branch be a release candidate?
| ^^^^^^^^^^ | ||
| Release tags must follow the format ``vX.Y.Z`` (for example, ``v2.9.0``). | ||
| - Full release tags must follow the format ``vX.Y.Z`` (for example, ``v2.9.0``). | ||
| - Release candidate tags follow ``vX.Y.ZrcN`` (for example, ``v2.10.2rc1``). |
There was a problem hiding this comment.
When would we tag a branch as release candidate?
| - name: Resolve publish config | ||
| id: config | ||
| run: | | ||
| if [[ "${{ github.event_name }}" == "workflow_dispatch" ]]; then |
There was a problem hiding this comment.
publish-wheels.yml (line 134) lets workflow_dispatch with destination: pypi bypass all tag checks. A maintainer can run this on any selectable ref and publish whatever version is in docs/source/bskVersion.txt to production PyPI. I’d either remove pypi from manual dispatch or require github.ref_type == 'tag' with a non-rc vX.Y.Z tag before setting the PyPI URL.
| process; however, it must now be updated manually to prevent excessive version | ||
| bumps. | ||
|
|
||
| Update this file to reflect the new version number following semantic versioning |
There was a problem hiding this comment.
releaseGuide.rst (line 48) now documents RC tags, but it still tells maintainers to set only MAJOR.MINOR.PATCH. Since package version comes from docs/source/bskVersion.txt, an RC tag like v2.10.2rc1 will only produce RC artifacts if that file is also set to 2.10.2rc1. Add the RC version-file step and the final release reset step so TestPyPI doesn’t get mislabeled beta/stable artifacts.
Description
Verification
N/A
Documentation
N/A
Future work
N/A