Skip to content

Update publish workflow to handle release candidates#1391

Open
ReeceHumphreys wants to merge 3 commits into
developfrom
feature/release-candidate-tag-handling
Open

Update publish workflow to handle release candidates#1391
ReeceHumphreys wants to merge 3 commits into
developfrom
feature/release-candidate-tag-handling

Conversation

@ReeceHumphreys
Copy link
Copy Markdown
Contributor

  • Review: By commit
  • Merge strategy: Merge (no squash)

Description

  • Updates the release workflow so that release candidate tagged builds publish to TestPyPI
  • Simplified a few things in the workflow
  • Added support for manual dispatch of the workflow. Mainly useful for creating release candidates and debugging wheel workflows in case of error.

Verification

N/A

Documentation

N/A

Future work

N/A

@ReeceHumphreys ReeceHumphreys force-pushed the feature/release-candidate-tag-handling branch from 97dcc90 to fc7e026 Compare May 10, 2026 22:18
@ReeceHumphreys ReeceHumphreys changed the title [#0000] Update publish workflow to handle release candidates Update publish workflow to handle release candidates May 10, 2026
@ReeceHumphreys ReeceHumphreys marked this pull request as ready for review May 10, 2026 22:18
@ReeceHumphreys ReeceHumphreys requested a review from a team as a code owner May 10, 2026 22:18
@ReeceHumphreys ReeceHumphreys self-assigned this May 10, 2026
@ReeceHumphreys ReeceHumphreys added the ci Continuous integration label May 10, 2026
@ReeceHumphreys ReeceHumphreys moved this to 👀 In review in Basilisk May 10, 2026
Copy link
Copy Markdown
Contributor

@schaubh schaubh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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``).
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When would we tag a branch as release candidate?

- name: Resolve publish config
id: config
run: |
if [[ "${{ github.event_name }}" == "workflow_dispatch" ]]; then
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

ci Continuous integration

Projects

Status: 👀 In review

Development

Successfully merging this pull request may close these issues.

2 participants