Make CI publish on release creation.

[BenediktBurger]

Requires also the following steps:

• Create environment release
• Add this configuration to trusted publishers on pypi
• Adjust RELEASE.md

[BenediktBurger]

This PR adds the workflow, however a few steps with admin rights in this repo / at pypi are still necessary. @cjermain , @bilderbuchi
If these steps are done, we can merge.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 58.48%. Comparing base (92175a1) to head (2b202bc).

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #1039   +/-   ##
=======================================
  Coverage   58.48%   58.48%           
=======================================
  Files         262      262           
  Lines       18198    18198           
=======================================
  Hits        10643    10643           
  Misses       7555     7555           

Flag	Coverage Δ
unittests	58.48% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[BenediktBurger]

Bump setup-python version to most recent version.

[bilderbuchi]

One thing I am not sure about is the change to the release workflow -- what happens if there is a problem/issue with creating the Python package?
Currently, this is caught because the packager does a package build and test upload to pypi/test from the local machine, and only tags afterwards.
With the new workflow, IIUC, one would finish the changelog, create a tag, push the tag, create a GH release on the web interface, and then the package is autocreated, which means problems would be discovered only after the tag has been created, which would necessitate another immediate bugfix release.

Or is this really an edge-case concern? I don't remember encountering a problem in the local package-building step before, so maybe it's not worth taking this into account, and the benefit of packaging automation by far outweighs that.

BTW, this PR should also update RELEASE.md with the updated workflow.

[BenediktBurger]

BTW, this PR should also update RELEASE.md with the updated workflow.

That is, what I meant with the gist, as I thought, the realease workflow is in a gist.
I updated the ToDos in the beginning.

With the new workflow, IIUC, one would finish the changelog, create a tag, push the tag, create a GH release on the web interface, and then the package is autocreated, which means problems would be discovered only after the tag has been created, which would necessitate another immediate bugfix release.

The created release is only a github release. You can delete it (and the tag), as it is unlikely, that someone pulled the tag in exactly the moment between creating a github release and the push to pypi.

I encountered it in pyleco, when I made a wrong tag name (dot between v and version), such that the creation failed. I deleted the github release and made a new one with the same commit.

[bilderbuchi]

You can delete it (and the tag), as it is unlikely, that someone pulled the tag in exactly the moment between creating a github release and the push to pypi.

Yeah, although this violates the general git best practice that public history should be immutable (which we mainly practice with main/develop branches anyway as we allow force-pushing PR branches). So, having this as the formal/defined way is something I would avoid. Personally, I've always shied away from recreating an already pushed tag.
Btw, it could be that a CI, bot or other automated process watching our repo would act on the fresh tag.

I'm wondering how other projects using that action see that concern, or if there's a FAQ or best practice defined?

[bilderbuchi]

Out of curiosity, did you see that you could also trigger the publish workflow on new tags? https://packaging.python.org/en/latest/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows/#defining-a-workflow-job-environment
Then the GH release is independent of the pypi stuff, and this manual part could be done afterwards.
Not sure what's better, I'm not particularly fond of the "Releases" thing which kinda mirrors/duplicates what Git tags already are for.

[BenediktBurger]

For pyleco, I did

• the draft release (keeping it open)
• created the changelog from there,
• pushed the changelog
• published the release

which worked well for me.

Not sure what's better, I'm not particularly fond of the "Releases" thing which kinda mirrors/duplicates what Git tags already are for.

I see it as a special form of tags: You have that prominent window, showing you, the current version and the last versions (you can have more tags than just versions).

Out of curiosity, did you see that you could also trigger the publish workflow on new tags?

I did not look for that.

[BenediktBurger]

Yeah, although this violates the general git best practice that public history should be immutable (which we mainly practice with main/develop branches anyway as we allow force-pushing PR branches). So, having this as the formal/defined way is something I would avoid. Personally, I've always shied away from recreating an already pushed tag.
Btw, it could be that a CI, bot or other automated process watching our repo would act on the fresh tag.

You have to create a tag for setuptools to succeed.
Therefore, if a build fails and you have to do a change (new commit), you have to create a second tag.
In this case you have to increase the patch number by one, I'd say.

We could do as a workflow either:

• mark a release only as "latest", after the publishing to PyPI succeeded (maybe that could be automated too?)
• publish to PyPI on tag creation and create a github release afterwards

Anyways, as you said, github releases are (for python packages on PyPI) not very important.

[BenediktBurger]

@bilderbuchi do you want to think about this, as a preparation for the 0.14 release?

[BenediktBurger]

I rebased on master

[bilderbuchi]

a few steps with admin rights in this repo / at pypi are still necessary.

not sure what you are referring to here, but AFAIK only Colin has the admin bit on this repo (but I could not confirm that, my settings view is quite limited). We should probably take this up with him by email, if we can extend that circle. Otherwise we'd have to again put him into the critical path for getting releases out.

[BenediktBurger]

a few steps with admin rights in this repo / at pypi are still necessary.

I referred to the tasks in the first post: creating the release environment and adding the release file to the trusted publishers on pypi.

Otherwise we'd have to again put him into the critical path for getting releases out.

No, once he has set it up, we don't need the admin rights anymore.

[bilderbuchi]

OK then, fine with me , also to try this out with the upcoming release. :-)

[BenediktBurger]

As Colin did the requirements, we can merge, I think.
@bilderbuchi?

[bilderbuchi]

As Colin did the requirements, we can merge, I think. @bilderbuchi?

LGTM!