Fix github actions for non-release tags

[shyamd]

This should fix #229 and ensure that the release workflow only runs on tags made via the release tab on Github. We should also start including changelog summaries in those release descriptions.

[codecov]

Codecov Report

Merging #235 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #235   +/-   ##
=======================================
  Coverage   87.57%   87.57%           
=======================================
  Files          43       43           
  Lines        1916     1916           
=======================================
  Hits         1678     1678           
  Misses        238      238

Flag	Coverage Δ
#unittests	87.57% <ø> (ø)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 3ead73d...9c3cef0. Read the comment docs.

[ml-evs]

@CasperWA was much more diligent than me when making releases. The PR's for the tagged commits have all the changes summarised (see the 0.6 tag). This looks like a sensible way of proceeding though!

EDIT: unfortunately it seems like you can't edit the description of a release post hoc.

[CasperWA]

This should fix #229 and ensure that the release workflow only runs on tags made via the release tab on Github. We should also start including changelog summaries in those release descriptions.

Yeah, I thought to at least put in the effort for each release, then it would be easy later to do proper GitHub releases, as well as add a CHANGELOG.md or something.

[CasperWA]

EDIT: unfortunately it seems like you can't edit the description of a release post hoc.

You can if you make it a proper release on GitHub. Go to tags and choose the tag you want to release, and release it :)

[CasperWA]

I don't know that this will work, but the release should do it, I belieeve.

[shyamd]

The combination of both do it.

[ml-evs]

Could we test it with some a pre-release tag?

[ml-evs]

(after merging)

[shyamd]

We can just do a patch release v0.7.1

[CasperWA]

The combination of both do it.

I'm not sure the github actions logic work this way, is my only concern. It's not AND statements, but rather OR as I understand it, but I may definitely be wrong, since it also seems to update a bit at the moment.

[CasperWA]

Seeing the actions run (here) it seems clear it's an OR logic, i.e., the workflow ran on a push to the branch master. But didn't release on PyPI only due to the check in the code that the version in __init__.py doesn't match.

[ml-evs]

EDIT: unfortunately it seems like you can't edit the description of a release post hoc.

You can if you make it a proper release on GitHub. Go to tags and choose the tag you want to release, and release it :)

Weird, assumed it would republish/duplicate the release based on the options I was given, but it has just updated it fine. So 0.6 and 0.7 now have the markdown changelogs. I don't think we need to worry about the others.

[ml-evs]

LGTM, let's test it once it's merged though with 0.7.1. Would you mind squash merging it @shyamd?

[CasperWA]

So I think this doesn't work.
Looking into the documentation of GitHub Actions The releases should be alongside push, not tags and branches.
Furthermore, I am now pretty sure this means that the workflow will run for pushes of tags that matches the pattern, as well as for branches matching master. I.e., the requirements for when the workflow will run has simply been expanded, not restricted.

However, there are two options as I understand it:

1. Either drop this, and only run the workflow upon publishing a release.
   This has the advantage that we need to create a proper GitHub release.
   The disadvantage is if the workflow/publication fails, I am not sure a GitHub published release can be deleted and redone?
2. Apply further constraints in the if value at jobs.publish.if. If it's possible to get information about the branch the commit is on that the tag is referring to, or similar, it will effectively do the AND constraint that was intended with this PR.
   This has the advantage of doing what the PR wanted (I presume), as well as making sure we only publish when pushing a valid tag to master.
   The disadvantage must be that we don't automatically enforce the GitHub releases?

Personally, I vote to try the second option first, and if it's not possible, then turn to option one?

[shyamd]

Let's try the second option.