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 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 publishing step won't be triggered until so.

[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.

[agriyakhetarpal]

Good news: this entire workflow is now all the more easy to implement with the GitHub Actions Attestations feature, which has been generally available for some time now. Let me restructure this PR later in the day, I'm happy to answer any questions as needed.

[agriyakhetarpal]

Having a place to put them permanently would serve some part of the reproducibility issues discussed

Once added, the attestations would become permanently available at https://github.com/ziglang/zig-pypi/attestations for anyone to download and verify.

[whitequark]

Sounds good.

[agriyakhetarpal]

Okay, this is ready now! I even added a short but nice (and extensible) Markdown summary for looking at what wheel artifacts were built: https://github.com/agriyakhetarpal/zig-pypi/actions/runs/11176994453/attempts/1#summary-31071679824. There is no hurry from my side for a review – I'm just always excited to contribute to this fantastic project that I get to use.

[agriyakhetarpal]

Attestations at the PyPI level now available, too, here's the announcement: https://blog.pypi.org/posts/2024-11-14-pypi-now-supports-digital-attestations/