Set up trusted publishing to PyPI

[disinvite]

Preview: https://test.pypi.org/project/reccmp/

I was experimenting with calver. We will user semver instead.

[jonschz]

Thanks for pushing this forward! A few points:

1. Relative links in the README at https://test.pypi.org/project/reccmp/ do not work. Not sure what the best course of action is - maybe a separate, shorter README for PyPI with a link to the full GitHub README?
2. At the moment, you are the only person with access to the PyPI project, correct? Not sure if we want to change that (bus factor etc.). I haven't looked into this, but can you give other people access to the PyPI project without having to share your account credentials? Edit: Addressed
3. I think we should also set up dependabot. I'll look into it -> #346 Edit: Addressed
4. Have you tested this flow somewhere? I couldn't find any runs. Edit: Addressed

I'll take another look once you've addressed these points. Feel free to request another review.

[jonschz]

General question: What is the workflow you intended here? Manually create a GitHub release and have the CI run on the tag being pushed? (Edit: I saw that you intend to create a release in this flow, so that's probably not what you had in mind). In that case, I'd set up a trigger like

on:
  release:
    types: [created]

Furthermore: If we stay on the push trigger, should we also restrict this to commits to the master branch that have a version tag? I don't think we should release from any branch other than master since they don't have branch protection.

Also, maybe we should create a PUBLISHING.md just to write down the workflow / procedure as a reference?

[disinvite]

In its current state:

1. Push the tag upstream.
2. Approve the build/publish step to run.

And the release is created from the tag. I wanted the build artifacts added to the release automatically so there's less potential for user error with a manual download/upload step. If there's a better way that begins with creating (draft) releases then that's probably better.

I tried adding branch: [master] to the YML but that ended up running the build action for any push to master, not the intended combination of v* tag and master push. If it's possible to add multiple conditions then we should have them.

[jonschz]

Fair enough. If you add a 3-sentence PUBLISHING.md, I'll consider this point to be resolved.

[disinvite]

Thanks for pushing this forward! A few points:

1. Relative links in the README at https://test.pypi.org/project/reccmp/ do not work. Not sure what the best course of action is - maybe a separate, shorter README for PyPI with a link to the full GitHub README?

2. At the moment, you are the only person with access to the PyPI project, correct? Not sure if we want to change that (bus factor etc.). I haven't looked into this, but can you give other people access to the PyPI project without having to share your account credentials?

3. I think we should also set up dependabot. I'll look into it -> #346

4. Have you tested this flow somewhere? I couldn't find any runs.

I'll take another look once you've addressed these points. Feel free to request another review.

1. Yes. I tried writing a shorter README this week but didn't come up with anything I liked. This could be a separate PR before we push the first (official) release. Maybe we could move the existing one to docs/main.md with a hard link to the main repo? At some point we might need a docs site, but that's out of scope for this.

2. Hadn't considered the bus factor 💀. Sent some DMs on this.

3. Yes, thanks for adding it.

4. I tested with Test PyPI on my fork on master. I wasn't sure if it would work in another branch because PyPI doesn't let you specify.

[jonschz]

Yes. I tried writing a shorter README this week but didn't come up with anything I liked. This could be a separate PR before we push the first (official) release. Maybe we could move the existing one to docs/main.md with a hard link to the main repo? At some point we might need a docs site, but that's out of scope for this.

A separate PR sounds nice. I'd prefer to leave the current README as-is since it fits the "GitHub project README" spirit quite well in my opinion. A second README for PyPI only would be preferable to me. Moving other markdown files to /docs would be fine with me, too.