CI: Publish workflow (PyPI)

[danielhollas]

This adds a GHA workflow for publishing to PyPI.

This uses the relatively new Trusted Publisher authentication mechanism, which does not require storing a secret token in repository settings (we should consider migrating aiida-core to this as well imo).

The workflow itself is triggered when a tag is created (Typically by creating a release on GitHub UI). Additionally, one can test the release by publishing to TestPyPI by adding a test-release label to a PR.

I have used this workflow in another (non-AiiDA) repository and it's been working well.

Closes #72

[danielhollas]

I don't think the __version__ attribute is very useful for this package and it complicates package management so I am removing it. Dissenters will be pointed to a lengthy discussion thread on CPython forum full of people arguing about this. :-D

[unkcpz]

Please point me to the lengthy discussion, would be a nice read material after dinner.

[danielhollas]

🤣

https://discuss.python.org/t/brainstorming-eliminating-dynamic-metadata/71405

Here you go. :-)

[danielhollas]

I decided to first publish a version 0.0.1 which should be fully backwards compatible and can be used by existing users.

[danielhollas]

@unkcpz @agoscinski can you take a look? Once I have a green light on this workflow I'll add instructions for maintainers into docs.

[danielhollas]

@unkcpz @agoscinski Also can you please send me your user names on PyPI so that I can add you as maintainers of the aiida-test-cache package? Let me know if other people should be added. Thanks!

[agoscinski]

Thanks for this PR @danielhollas . I myself was wondering recently how to do properly test releases in the CI. I think the PR is good as it is. My pypi account is alexgo (on test and regular). Just some questions:

Would be better to invoke the test release when pushing a tag to a branch that is not main? This way you also run check-release-tag for the test release.

---

This uses the relatively new Trusted Publisher authentication mechanism, which does not require storing a secret token in repository settings (we should consider migrating aiida-core to this as well imo).

Is it worth the effort? It seems just more convenient to set up but there seems to be no advantage when already having it set up.

---

[danielhollas]

Would be better to invoke the test release when pushing a tag to a branch that is not main? This way you also run check-release-tag for the test release.

I agree that this would be better, but I don't think it's possible, since in the Github actions there is no way to distinguish whether the tag is pushed to the main branch or different branch. Once the tag is pushed, the tag push event is fired and the workflow runs.

I've spent a lot of time trying to find a good solution for AiiDAlab repositories, but in the end did not end up with something fully satisfactory. For example, in aiidalab-widgets-base, we trigger the test release based on a branch name

https://github.com/aiidalab/aiidalab-widgets-base/blob/26773684a5b671bfcb9cee4ade248e7978bc26ff/.github/workflows/publish.yml#L11

a kind of like the label solution better, since it's kind of easy to forgot to name the branch appropriately.

Also in the above case, we trigger the actual release not a tag creation, but on publishing a release on GitHub.

https://github.com/aiidalab/aiidalab-widgets-base/blob/26773684a5b671bfcb9cee4ade248e7978bc26ff/.github/workflows/publish.yml#L13

The idea there was to avoid accidental release when someone would push a tag by accident.

In any case, for this small repo I wanted for the process to be as simple as possible so I think what we have here now is ok.

[danielhollas]

Is it worth the effort? It seems just more convenient to set up but there seems to be no advantage when already having it set up.

The main advantage is security, since long living secret tokens can be stolen. This is not a theoretical threat either, for example Codecov (which we use!) had a major breach couple years ago where attackers where targeting secrets on Github repos https://about.codecov.io/security-update/

I don't know how much effort it is to convert an existing project to this workflow. I can try to do it for one of the AiiDAlab repos and let you know.

[agoscinski]

Thanks for the detailed explanation. I am still not entirely sure if the trust relation between GitHub and the provider that needs to be established for the OIDC is not just moving the security problem to somewhere else but I guess people have thought this through.