Revising the release process

[ajjackson]

Discussion with @oerc0122

The existing release process for Euphonic is at https://github.com/pace-neutrons/pace-developers/blob/master/euphonic/development/02_releases.md

• There are some manual steps that could be removed/consolidated
• The test_release action always fails at first while waiting for Conda. It can be a bit unclear what this is for and perhaps should be split into test_PyPI and test_conda workflows

As we move to a meson-based build system and rework the corresponding actions, it might be wise to have a single action which:

• Updates version numbers in euphonic.version, CITATION.cff
• Renames the "Unreleased" CHANGELOG section to reflect new version number and creates a new "Unreleased" section
• Commit these changes to master
• Builds wheels with new version number (which cannot be read from git tag at this point) and tests from wheels
• IF builds and tests are successful, create new tag, push to GitHub
• Create GitHub release from CHANGELOG (Github is quite forgiving about editing this later)
• Push wheels to PyPI

[mducle]

I think the "Push wheels to PyPI" should be a separate manual action because you can only do it once (PyPI will not allow you to modify a release), so there's a high chance something will go wrong even if you make it through all the stages of the action successfully... I'd stop the automatic release action at the GitHub release stage, then manually test the wheels created in the GitHub release and if they were good then upload it to PyPI...

The system I used with libpymcr is to have an action run if there is RELEASE in the PR title and the PR is merged. This creates a GitHub release, then it runs the normal pipeline (which runs the test and creates the wheels) but the normal pipeline then detects it is a release and uploads the wheels to the release when it succeeds. The main probably with this workflow is that you have to merge the PR to trigger the release so if the release action has a bug / fails somehow you have to create a new PR. So, you could do something like this but manually triggered using a workflow_dispatch which takes the version number as an input.

[ajjackson]

Our initial thought was also to be wary of the push to PyPI step, but...

Once we've run a test suite on the already-built wheels, what other reassurance are we waiting for? What is the likely failure scenario that doesn't kill the Action first?

Currently cibuildwheel is used for the manylinux builds; this has a feature to automatically run isolated tests from the wheel after it is built. It could be a good idea to use this for the other platforms as well, and simplify things a bit. (As pointed out by @oerc0122 )

[mducle]

Yeah, I think using cibuildwheel for everything is a good idea. The one time I had to overwrite a PyPI release was due to missing docs so as you say it's quite an edge case. Since I put in the two-step thing there was one time where it caught that there was a missing file needed for a function which was not tested in the CI but which new users would run only on the first run.