ci: publish releases via PyPI trusted publishing - #708
Draft
tobixen wants to merge 1 commit into
Draft
Conversation
The manual release dance was long enough that the RELEASE-HOWTO's own list of mistakes had eight entries. Pushing a signed tag now does the mechanical part: build, check the tarball, smoke-test the wheel, upload over OIDC, create the github release from the tag message. Two guards against burning a version number, since a PyPI upload cannot be undone: workflow_dispatch runs everything except the upload, so the workflow can be rehearsed, and the publish job sits in a `pypi` environment that can be given required reviewers. Tag-signature verification is deliberately not implemented yet - the recipe is written down in the HOWTO for the next patch release. The companion niquests-free alpha keeps being tagged from the laptop on a throwaway branch; it just rides the same workflow now. Its wheel declares no HTTP library at all, so the smoke test only demands a bare import from the declared dependencies. NOT MERGEABLE AS IT STANDS: trusted publishing has to be registered under the PyPI project's settings, and caldav is owned by Cyril rather than by me. Merging before that is done would replace a working manual procedure with a workflow that fails at the upload step. Hence the draft PR - the code is ready, the PyPI side is the open question. Prompt: The RELEASE-HOWTO is a bit too combersome now. Can we set up trusted publishing? Ideally I'd like the "3.x.ya1 should be without niquests dependency"-logic to be embedded in the github CI workflow, but it's difficult with testing etc, so probably best that I push separate 3.x.ya1 and 3.x.y from the laptop (eventually this can be scripted from the laptop side). There are some notes on how the "trusted publishing" is set up for other projects in /python-project-modernization and in ~/caldav-server-tester, ~/icalendar-searcher, ~/plann etc. I wouldn't like to burn a version number now due to mistakes in the github CI workflow. I would like to set up some protection in the CI worflow to verify that the tag is signed by me, but that can wait until the next patch-release. It should be documented somewhere though. Followup-Prompt: Oh, I don't have permissions to set up trusted publishing on pypi as the project is owned by cyril. I'll have to go with the old workflow today. Followup-Prompt: wouldn't it be easier to just leave the branch where it was for future visits (maybe push it as a PR, roll back to master and reapply my changes to the HOWTO-document? With a PR, I can eventually ask Cyril to have a look at it. But it should be in draft mode, I'd like to hand-edit the prose myself when I get time for it. AI-assisted: Claude Opus 5 via Claude Code AI Prompts: claude-sonnet-4-6: wouldn't it be easier to just leave the branch where it was for future visits (maybe push it as a PR, roll back to master and reapply my changes to the HOWTO-document? With a PR, I can eventually ask Cyril to have a look at it. But it should be in draft mode, I'd like to hand-edit the prose myself when I get time for it.
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.
AI-generated contents below. It will be rewritten before this pull-request leaves "draft mode".
The manual release dance was long enough that the RELEASE-HOWTO's own
list of mistakes had eight entries. Pushing a signed tag now does the
mechanical part: build, check the tarball, smoke-test the wheel, upload
over OIDC, create the github release from the tag message.
Two guards against burning a version number, since a PyPI upload cannot
be undone: workflow_dispatch runs everything except the upload, so the
workflow can be rehearsed, and the publish job sits in a
pypienvironment that can be given required reviewers. Tag-signature
verification is deliberately not implemented yet - the recipe is written
down in the HOWTO for the next patch release.
The companion niquests-free alpha keeps being tagged from the laptop on
a throwaway branch; it just rides the same workflow now. Its wheel
declares no HTTP library at all, so the smoke test only demands a bare
import from the declared dependencies.
NOT MERGEABLE AS IT STANDS: trusted publishing has to be registered
under the PyPI project's settings, and caldav is owned by Cyril rather
than by me. Merging before that is done would replace a working manual
procedure with a workflow that fails at the upload step. Hence the
draft PR - the code is ready, the PyPI side is the open question.
Prompt: The RELEASE-HOWTO is a bit too combersome now. Can we set up
trusted publishing? Ideally I'd like the "3.x.ya1 should be without
niquests dependency"-logic to be embedded in the github CI workflow,
but it's difficult with testing etc, so probably best that I push
separate 3.x.ya1 and 3.x.y from the laptop (eventually this can be
scripted from the laptop side). There are some notes on how the
"trusted publishing" is set up for other projects in
/python-project-modernization and in ~/caldav-server-tester,
~/icalendar-searcher, ~/plann etc. I wouldn't like to burn a version
number now due to mistakes in the github CI workflow. I would like to
set up some protection in the CI worflow to verify that the tag is
signed by me, but that can wait until the next patch-release. It
should be documented somewhere though.
Followup-Prompt: Oh, I don't have permissions to set up trusted
publishing on pypi as the project is owned by cyril. I'll have to go
with the old workflow today.
Followup-Prompt: wouldn't it be easier to just leave the branch where it
was for future visits (maybe push it as a PR, roll back to master and
reapply my changes to the HOWTO-document? With a PR, I can eventually
ask Cyril to have a look at it. But it should be in draft mode, I'd
like to hand-edit the prose myself when I get time for it.
AI-assisted: Claude Opus 5 via Claude Code