chore: Create release workflow

[Christopher-Chianelli]

The workflow cannot be tested in full until 1.10 is out (since 1.9.0 is missing classes we use), but I tested on my own repo (replacing ref: v${{ github.event.inputs.version }} with ref: main).

Due to the particularities of GitHub, a manual action cannot be run unless it has a file in the main branch, but once it has a file on the main branch, you can run the action using a different branch.

[Christopher-Chianelli]

(Will add the PyPI action when we are ready to publish, since once a package on PyPI, it is impossible to retract it, and we don't want to accidentally publish it when testing the rest of the workflow).

[triceo]

@Christopher-Chianelli There is no staging workflow? That's unfortunate - because occasionally releases fail and it is so much easier to just delete an artifact from staging and restart the entire release, as opposed to writing CI that can restart itself from a particular point in the release.

[Christopher-Chianelli]

@triceo See https://github.com/pypi/warehouse/issues/726, which would be a proper "staging" workflow. Currently, the "staging" workflow is to upload to test.pypi, which is another public index and verify the README.md renders correctly. What other companies do is upload the package to their own "staging" server.

[triceo]

@Christopher-Chianelli Does JReleaser support any of that? If not, then arguably it doesn't much matter what we choose.

[Christopher-Chianelli]

@triceo JReleaser does not explicitly support a "publish to PyPI" workflow. But it can attach the built wheel to the GitHub release. https://github.com/marketplace/actions/pypi-publish is what will be used to publish the package to PyPI.

[aalmiray]

@Christopher-Chianelli happy to help figuring out what's needed from JReleaser's side to publish to PyPI as we do with other targets 😄

[Christopher-Chianelli]

@aalmiray Currently, we use https://github.com/pypa/gh-action-pypi-publish to publish to PyPI.

The documentation of the current PyPI API is available at https://peps.python.org/pep-0694/#status-quo. Only the "Status Quo" section in relevant, since the rest of the PEP is a proposal on a new upload API still in draft.

How twine (the package uploader the action uses) uploads a package is

https://github.com/pypa/twine/blob/6fbf880ee60915cf1666348c4bdd78a10415f2ac/twine/repository.py#L129-L200

Ideally, a "PyPI publish" should:

• Support username/password authentication.
• Support token authentication (where username = __token__ and the password is the token, including the pypi- prefix).
• Support trusted publishing/OpenID Connect authentication (which is token authentication, but uses a short-lived token generated by the workflow)
• Support uploading to PyPI (https://upload.pypi.org/legacy/) and TestPyPI (https://test.pypi.org/legacy/)
• Support uploading to a private repository that mirrors the PyPI API.
• Specifying the files to upload (default: files in dist, which have extensions .whl (Wheel) and .tar.gz (Source archive), see https://packaging.python.org/en/latest/discussions/package-formats/).

Optional/nice to have:

• Verify the contents of the metadata uploaded is valid, see https://github.com/pypa/twine/blob/6fbf880ee60915cf1666348c4bdd78a10415f2ac/twine/commands/check.py#L32-L164.