Revert "Fix github actions for non-release tags"

[shyamd]

Reverts #235

[codecov]

Codecov Report

Merging #236 into master will not change coverage by %.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #236   +/-   ##
=======================================
  Coverage   87.33%   87.33%           
=======================================
  Files          43       43           
  Lines        1943     1943           
=======================================
  Hits         1697     1697           
  Misses        246      246           

Flag	Coverage Δ
#unittests	87.33% <ø> (ø)

---

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 55c84c3...d2e1fba. Read the comment docs.

[CasperWA]

Cool.
So, I have been testing some stuff on my fork and have come to the following conclusion(s):

• When one creates a tag, it will become part of that repository's list of tags, no matter the commit (in the specific repository) it is made to point to. Since we've been working on Materials-Consortia branches for the release PRs, the tag is created for the Materials-Consortia repository, even when pushing the tag in a PR.
  In the end, this means, even when the PR is merged, there are no tag pushes from whatever branch to master, since the tag is simply a "symlink" (of sorts) to a commit SHA. That the commit has now become part of master makes no difference. Even if the commit doesn't exist in any branch anymore, the tag will persist.
• Setting a workflow to run on "push to master", will result in a GitHub context containing the commits in the PR, which are now in master. There is no reference or information about linked tags to any commits - and it also wouldn't make sense, since a tag has no influence on the commits in a branch.

So - we should decide on a workflow that will work for us.

1. Either we keep the workflow running on "push specific kind of tag" and make sure to only create and push these tags on commits already in master, so as to not publish a tag pointing to a pre-mature commit. I.e., one creates a PR to update the code with the new version, has it merged, and immediately creates a tag and pushes it, starting the workflow (as has been the way to do it up to now).
2. Or we decide to instead rely on creating GitHub releases, which will in turn start the Actions workflow to publish on PyPI as well. This means nothing will happen when creating and pushing tags, only when publishing/releasing a tag on GitHub. (EDIT: Chosen option)

Personally, I don't mind which it will be.

[ml-evs]

I much prefer 2, as a great many people have write access to this repo, and just pushing a versioned tag to their own branch will lead to a PyPI release, which potentially runs on many servers, who are potentially automatically updating dependencies... etc.

[shyamd]

I also vote for the second option. There needs to be step that initiated only for a release so it doesn't accidentally happen.

[CasperWA]

I much prefer 2, as a great many people have write access to this repo, and just pushing a versioned tag to their own branch will lead to a PyPI release, which potentially runs on many servers, who are potentially automatically updating dependencies... etc.

If they first change the if statement in the workflow, yes.

[CasperWA]

All right! I'll push the solution for option number 2 to this PR, after I have tested it a bit in my fork first 👍

[ml-evs]

I much prefer 2, as a great many people have write access to this repo, and just pushing a versioned tag to their own branch will lead to a PyPI release, which potentially runs on many servers, who are potentially automatically updating dependencies... etc.

If they first change the if statement in the workflow, yes.

What do you mean? I managed to make a release off my own personal branch without changing anything

[CasperWA]

I much prefer 2, as a great many people have write access to this repo, and just pushing a versioned tag to their own branch will lead to a PyPI release, which potentially runs on many servers, who are potentially automatically updating dependencies... etc.

If they first change the if statement in the workflow, yes.

What do you mean? I managed to make a release off my own personal branch without changing anything

Ah! Hmm... yeah okay - from a PR then? I guess the if statement is not that much of a show stopper in the end then.

[CasperWA]

On another note, related to my "conclusions" above. It should be considered bad practice to create and push a tag on a PR commit, before the PR is merged. Since, if the PR is squashed and merged or rebased and merged, the tag will persist, but point to a non-historical/-existing commit.
If one has done this, however, it can still be okay, but only if the PR is merged from the commandline using git merge --ff-only - or merging including a merge commit. However, then the master will be already 1 commit ahead of the latest release without having actually added an extra real commit ....

[CasperWA]

After merging this, we can test it by releasing the v0.7.1 tag on GitHub? Unless we want to actually set it to point to this PR instead?

Edit: I have just deleted the test release for v0.7.1. I think I would suggest we also remove the v0.7.1 tag and recreate it for the latest commit here?

[CasperWA]

@shyamd do you approve my commit? Then I'll approve on your behalf and we can merge :)

[shyamd]

I approve of this PR.

[CasperWA]

Approved on behalf of @shyamd