Skip to content

add release trigger that takes a tag as input#3821

Merged
d-v-b merged 1 commit intozarr-developers:mainfrom
d-v-b:chore/publish-retroactive
Mar 23, 2026
Merged

add release trigger that takes a tag as input#3821
d-v-b merged 1 commit intozarr-developers:mainfrom
d-v-b:chore/publish-retroactive

Conversation

@d-v-b
Copy link
Contributor

@d-v-b d-v-b commented Mar 23, 2026

This change to release.yml should allow us to use workflow-dispatch, i.e., manual triggering,
to invoke the release workflow, with an explicit tag as input. This supports publishing a tagged
release outside of the commit that creates that tag. This is useful for situations where we issued a
release, but the github actions workflow was broken in some way that prevented us from uploading the
release to pypi.

We can also try pushing to test pypi via the same workflow-dispatch mechanism.

This change to `release.yml` should allow us to use `workflow-dispatch`, i.e., manual triggering,
to invoke the release workflow, with an explicit tag as input. This supports publishing a tagged
release outside of the commit that creates that tag. This is useful for situations where we issued a
release, but the github actions workflow was broken in some way that prevented us from uploading the
release to pypi.
@d-v-b d-v-b requested a review from maxrjones March 23, 2026 13:04
Comment on lines +98 to +102
- name: Publish package to Test PyPI
uses: pypa/gh-action-pypi-publish@v1.13.0
if: ${{ github.event_name == 'workflow_dispatch' && inputs.test_pypi }}
with:
repository-url: https://test.pypi.org/legacy/
Copy link
Member

Choose a reason for hiding this comment

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

I don't think this will work without a token added or OIDC setup. Auth for test PyPI is distinct from PyPI

@maxrjones
Copy link
Member

I think this is a clever solution to #3755 (comment), but would rather not have this generally available. For example, I wouldn't want anyone to be able to easily re-publish the prior releases that we've yanked from PyPI.

Would you consider just adding an option to deploy 3.1.6 via a workflow dispatch, which we will remove after?

The test PyPI additions are helpful.

@d-v-b
Copy link
Contributor Author

d-v-b commented Mar 23, 2026

I think this is a clever solution to #3755 (comment), but would rather not have this generally available. For example, I wouldn't want anyone to be able to easily re-publish the prior releases that we've yanked from PyPI.

Would you consider just adding an option to deploy 3.1.6 via a workflow dispatch, which we will remove after?

The test PyPI additions are helpful.

I assumed you can't unyank a release, but either way I'm totally fine reverting these changes after we use them to publish 3.1.6. That's the only real reason for doing this PR, once it has fulfilled its purpose the changeset here can be reverted.

@d-v-b d-v-b merged commit 9fa1016 into zarr-developers:main Mar 23, 2026
23 checks passed
@d-v-b d-v-b deleted the chore/publish-retroactive branch March 23, 2026 16:05
d-v-b added a commit to d-v-b/zarr-python that referenced this pull request Mar 24, 2026
…3822

Reverts our `releases.yml` workflow to the state as of 93dd0e4, i.e. no option to publish a tag declared in workflow dispatch.
d-v-b added a commit that referenced this pull request Mar 24, 2026
Reverts our `releases.yml` workflow to the state as of 93dd0e4, i.e. no option to publish a tag declared in workflow dispatch.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants