Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CI: Automate pypi wheel publishing #689

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

WillAyd
Copy link
Contributor

@WillAyd WillAyd commented Nov 21, 2024

ref #660

This is currently pointing to the test pypi environment and we can trigger manually for now

@WillAyd
Copy link
Contributor Author

WillAyd commented Nov 21, 2024

Before we try this I think we will need to enable trusted publishing in pypi (better to start with the test environment)

https://packaging.python.org/en/latest/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows/#configuring-trusted-publishing

Comment on lines +22 to +23
release:
types: [published]
Copy link
Member

Choose a reason for hiding this comment

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

Wheels are not signed during release right? Otherwise I'd say download the wheels from the release and push those. (Or make use of reproducible builds)

.github/workflows/pypi_publish.yml Show resolved Hide resolved
Copy link
Member

@paleolimbot paleolimbot left a comment

Choose a reason for hiding this comment

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

Thank you for looking into this!

I have to admit that what I had in mind was from the local end...something like "find the wheels job on the RC branch:

run_id=$(gh run list \
--repo "${REPOSITORY}" \
--workflow=packaging.yaml \
--json 'databaseId,event,headBranch,status' \
--jq ".[] | select(.event == \"push\" and .headBranch == \"${tag}\") | .databaseId" | \
head -n 1)

...then download artifacts ( https://cli.github.com/manual/gh_run_download ), then twine to upload.

Something like this can work too, although there is a bit of a chicken-and-egg problem with the Apache vote: the wheels will have already been built against the release commit before the release candidate vote happens, and we need to upload them after the release vote passes. (Not technically a problem since binaries aren't technically voted on, just not strictly necessary).

@assignUser
Copy link
Member

You could add the wheels to the github release (though I think they might need to be signed then?) and use these in the workflow (or just use gh to get them as in your example)

the wheels will have already been built against the release commit before the release candidate vote happens, and we need to upload them after the release vote passes.

I don't see the issue? I assume you publish the github release once the vote is finished? That would trigger this workflow and get the wheels voted on and upload them?

@paleolimbot
Copy link
Member

As written this PR would build new wheels after the release vote. If possible it would be nice to download the wheels that had already been built instead of building new ones (mostly so that when the release vote ends, all the release steps can happen immediately instead of waiting for a CI job). It is also slightly awkward if that CI job fails for whatever reason.

We could make it a script and put it in this CI job (and then if the CI job fails, you can run it locally)?

@assignUser
Copy link
Member

Ah yeah, we were talking about the same thing ^^ +1

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.

3 participants