Automate cutting new releases #1141
Conversation
| if [[ "$GITHUB_EVENT_NAME" == "push" ]]; then | ||
| export TWINE_REPOSITORY_URL="https://test.pypi.org/legacy/" | ||
| export TWINE_PASSWORD="${{ secrets.TEST_PYPI_UPLOAD_TOKEN }}" | ||
| elif [[ "$GITHUB_EVENT_NAME" == "release" ]]; then |
There was a problem hiding this comment.
I think we should either trigger on "release" or on workflow_dispatch, but not on both.
I'm inclined to say that we do it on workflow_dispatch.
There was a problem hiding this comment.
Note triggering in workflow dispatch will allow us to test things. It will generate dev versions (as there won't be a tag) that will be uploaded to test.pypi.org.
Why do you think this is a bad idea? At the very least as a way to test changes in the publish logic?
There was a problem hiding this comment.
I went ahead and made this change myself.
There was a problem hiding this comment.
I think you have it backwards. For the other repos I have using this same workflow, the workflows were designed before "manually trigger an action" was a thing you could do, so I was using "made a GitHub release" as a way to get a manual step I could take in the UI to trigger the "final" release.
The way you've got it wired up, manual triggers and making a GitHub release both trigger the "do a final release" pipeline, which is unnecessary, and whichever one happens second will fail anyway, so I've just changed it so that the manual workflow triggering is the only way to finalize. We can still make GH releases, but we'll do it after everything is published to PyPI.
|
I've updated some of the documentation here to be more explicit because despite having basically the same workflow on multiple projects, I always forget what I'm doing when I actually go to make a release. I've also gone ahead and modified the I should probably do the final rebase and merge for this one, so that the commit where I change the documentation about how we sign our releases can be signed by the same key that made all the releases, so that anyone who is putting their trust in that key can at least see that — to the standard of "author has the key" — the person who made the docs changes controls they key. |
.github/workflows/publish.yml
Outdated
| @@ -0,0 +1,56 @@ | |||
| # This workflow is triggered three ways: | |||
| # | |||
| # 1. When a tag is created, the workflow will upload the package to | |||
There was a problem hiding this comment.
You need to update these docs as well then
There was a problem hiding this comment.
Ah, I see what's happened here. You had intended workflow_dispatch as a way to trigger test PyPI uploads, but when you coded it up you had workflow_dispatch doing the final version.
I actually forgot that setuptools_scm will do that whole "dirty commit" signature if you do a build without a tag, which certainly makes your proposed workflow more attractive.
I suppose I'm fine with either way, whichever works for you.
There was a problem hiding this comment.
That is indeed exactly what I intended. Mirroring the workflow in tzdata but with an additional way to test the workflow.
There was a problem hiding this comment.
I'm also OK with this workflow, but we will need to remember triggering the releases manually (maybe that is actually a good thing)
pganssle
force-pushed
the
pu/auto-relase
branch
3 times, most recently
from
3029d80
to
6b8fc29
Compare
This replaces the manual workflow that involved invoking `release.py` with a GitHub workflow triggered either manually or via pushing tags and cutting releases.
The industry is moving away from GPG signatures, and signing distribution artifacts will complicate the release process and make it harder to allow other maintainers to make releases for only minor gain in auditability of releases. At least for now, we'll remove any guarantees about signatures and trust GitHub's authentication. Note: This commit is signed with the same key that signed releases 2.4.1-2.8.2.
|
@mariocj89 I think this is ready to go. I liked your idea better about manually triggering the workflow so I updated the releasing documentation and fixed up the logic for that. I wasn't able to test the manual triggering because apparently you need to merge before the button shows up, which is kind of annoying. Theoretically we could get fancy with it and add an input to the manual trigger that allows us to select between Test PyPI and normal PyPI, but I'm going to say YAGNI and let's ship it. Do you want to give this a once over before we merge? |
Use a GitHub workflow to simplify cutting new releases and avoid
potential mistakes.
Summary of changes
Closes
Pull Request Checklist