Here's a PR with a Continuous Deployment workflow that should automatically build packages and push them to PyPI every time a GitHub release is made, as described in #33.
Besides the workflow, this requires some set-up to get PyPI and GitHub to work together. This used to be done using a long-lived access token, which PyPI would generate and which you would then put into GitHub as a secret, but that's been succeeded by a new system called OpenID.
If I get it right, this has GitHub log in to PyPI using its own credentials, and then it hands PyPI a signed statement that it's running a particular workflow. PyPI verifies that it's really talking to GitHub and that the statement was signed by it, and then gives GitHub a temporary token, essentially a cookie. This is then used by the rest of the workflow to push the packages. As a result, there are no long-lived tokens that can be leaked. (Except for a certificate or a private key or something at GitHub, but that's easier to secure.) All this is built into the pypa/gh-action-pypi-publish action.
There's a second security feature, which is the use of a GitHub environment. I'm not sure exactly what that adds if you're the only one with access to the repository, but it allows you to set rules on whether and when a workflow runs, which makes it harder for people with commit but not admin access to do something malicious. I've linked the documentation below and leave it to you to set this up in just the way you want.
There's a lot of documentation on all this, so I've dug through it and found the relevant parts and put together some instructions. Untested but after careful reading this should at least be pretty close to working.
[ ] Follow the instructions to create an environment
It should be named pypi as that's what the workflow refers to. You can set up rules as you like, perhaps mark yourself as a "Required reviewer" so that others with access to the repository cannot change e.g. setup.py and run it without your permission. No secrets are needed, because we're using OpenID.
[ ] Make an account on PyPI, if you don't have one
[ ] Click on your account name at the top right and select "Your projects" in the menu
[ ] Click "Publishing" in the menu on the left
This will let you "Add a new pending publisher", which we need to do because we don't have a project yet. This deviates slightly from the documentation linked above, which is for if you already have PyPI releases.
[ ] Choose the GitHub tab, fill out the following values, and click Add:
PyPI Project Name: transiflow
Owner: BIMAU
Repository name: transiflow
Workflow name: cd.yaml
Environment name: pypi
PyPI will now check that any request to publish will come from GitHub, and that GitHub claims to be running the specified workflow. And it will automatically create a transiflow project on the first release.
Make a release
If you now make a release on GitHub, the workflow should run, building the packages (source and wheel) and publishing them on PyPI.
For subsequent releases, you'll want to update the version both in setup.cfg and in doc/conf.py, there's no automation around that in this PR.
Here's a PR with a Continuous Deployment workflow that should automatically build packages and push them to PyPI every time a GitHub release is made, as described in #33.
Besides the workflow, this requires some set-up to get PyPI and GitHub to work together. This used to be done using a long-lived access token, which PyPI would generate and which you would then put into GitHub as a secret, but that's been succeeded by a new system called OpenID.
If I get it right, this has GitHub log in to PyPI using its own credentials, and then it hands PyPI a signed statement that it's running a particular workflow. PyPI verifies that it's really talking to GitHub and that the statement was signed by it, and then gives GitHub a temporary token, essentially a cookie. This is then used by the rest of the workflow to push the packages. As a result, there are no long-lived tokens that can be leaked. (Except for a certificate or a private key or something at GitHub, but that's easier to secure.) All this is built into the
pypa/gh-action-pypi-publishaction.There's a second security feature, which is the use of a GitHub environment. I'm not sure exactly what that adds if you're the only one with access to the repository, but it allows you to set rules on whether and when a workflow runs, which makes it harder for people with commit but not admin access to do something malicious. I've linked the documentation below and leave it to you to set this up in just the way you want.
There's a lot of documentation on all this, so I've dug through it and found the relevant parts and put together some instructions. Untested but after careful reading this should at least be pretty close to working.
Create an Actions environment on GitHub
Documentation
pypias that's what the workflow refers to. You can set up rules as you like, perhaps mark yourself as a "Required reviewer" so that others with access to the repository cannot change e.g. setup.py and run it without your permission. No secrets are needed, because we're using OpenID.Set up PyPI
Documentation
PyPI will now check that any request to publish will come from GitHub, and that GitHub claims to be running the specified workflow. And it will automatically create a
transiflowproject on the first release.Make a release
If you now make a release on GitHub, the workflow should run, building the packages (source and wheel) and publishing them on PyPI.
For subsequent releases, you'll want to update the version both in
setup.cfgand indoc/conf.py, there's no automation around that in this PR.