Add a workflow to release and sign wheels

[agriyakhetarpal]

Description

Partially addresses issues raised in #20. This PR adds a workflow to release wheels to PyPI and sign them.

These changes are in response to the comment:

I think we can start with a workflow responding to workflow_dispatch event where the workflow itself uses both Sigstore and Trusted Publishing, with the pushing of wheels still being manual. Then we can consider something more automated after that.

and the workflow is meant to be triggered manually.

Changes made

1. A workflow that responds to the manual workflow_dispatch: trigger, with customisable inputs for enabling the version to build wheels for, the suffix to append to the version, platforms to build wheels for (might be redundant), and lastly, a push_to_pypi input which is false by default, but can be set to true to trigger the deployment job.
2. The deployment job is separate from the job that builds wheels because to isolate the environment associated with the job, and the extra permissions that it requires. Artifacts (in this case, wheels) are shared between jobs.
3. The deployment job signs the wheels and generates .sigstore files, which can be used to verify that the wheels were indeed generated inside a GitHub Actions workflow.

Additional context

To further mitigate actors bearing malicious intent, I would recommend adding a CODEOWNERS file or some sort of branch protection so that it is not easy for others to modify the workflow and trigger it. Currently, those with triage access can trigger workflows. The environment with the name pypi has to be set up and requests to use it to deploy have to be manually approved by a repository administrator or someone with the appropriate permissions, so, I would recommend keeping that stringent

[agriyakhetarpal]

This might be overkill as well – I was just experimenting with this locally, so it can be good if you don't wish to build too many wheels at once, but if a wheel or architecture has to be backported for a particular version, it can be useful.

[agriyakhetarpal]

Suggested change

	required: false
	required: true

It might make sense to make this a required input so that the user is aware of what is being input here.

[agriyakhetarpal]

This environment will have to be created in the repository settings, as noted in the PR description. It will trigger the workflow, but the deployment will pass only if it gets approved, and the workflow won't be triggered until so.

[agriyakhetarpal]

The artifact retention policy for GitHub Actions artifacts, which are, in this case, the files generated from Sigstore, is set to default to 90 days from the completion of the workflow (not sure what the upper limit is). Having a place to put them permanently would serve some part of the reproducibility issues discussed. The available options are:

1. Publish them to GitHub Releases: and releases require git tags, which is something that was objected to and we agreed not to do
2. Upload them in a folder in the repository in a manual commit after downloading them (not the wheels though, of course)
3. Upload them to a pinned issue and store them in the issue comments
4. and so on.

I think the second one is the best option at this time, because users can download and use those to verify them.

[agriyakhetarpal]

I'll move this to the context of the step that uploads to PyPI instead of the entire job, because we can have scenarios where we want to build a wheel, upload to PyPI manually (locally) using twine, but also have the Sigstore files associated with it as marker that the upload has been signed.

This can be useful in cases like #18 where PyPI already has Zig wheels for some platforms for a particular version, and one needs to build extra wheels for two versions, so instead of doing so locally, one can do it from here by triggering the workflow twice, and push the Sigstore files somewhere later to establish their permanence.

[agriyakhetarpal]

Addressed in cf9845e.

[agriyakhetarpal]

Here's a brief implementation as requested, @whitequark – would appreciate general comments based on how you would like to refine it and whether it fits with the ideas that you had in mind :)

[whitequark]

Thanks, impressive work! I won't have time to review it until a week or two from now most likely.