fix: Correct reference check in GitHub Actions publish to TestPyPI step

[kratsg]

Description

This adds in changes to #639. GHA triggers pushes on PRs as well... so you can't tell if a push event comes from a PR or not. Also need to fix logic of whether to use scm or not depending on if we're tagged or not.

Checklist Before Requesting Reviewer

• Tests are passing
• "WIP" removed from the title of the pull request
• Selected an Assignee for the PR to be responsible for the log summary

Before Merging

For the PR Assignees:

• Summarize commit messages into a comprehensive review of the PR

* More fixes to workflow in #639, only push to testpypi on pushes on master
* Only use scm if the current commit is not tagged
* Protect forks from publishing

[codecov]

Codecov Report

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

@@           Coverage Diff           @@
##           master     #640   +/-   ##
=======================================
  Coverage   94.93%   94.93%           
=======================================
  Files          42       42           
  Lines        2547     2547           
  Branches      345      345           
=======================================
  Hits         2418     2418           
  Misses         85       85           
  Partials       44       44

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

---

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 6f50690...2df6ea8. Read the comment docs.

[matthewfeickert]

For posterity, to document the logic that is being used here that @kratsg had to explain to me as I missed it: Given that

GHA triggers pushes on PRs as well... so you can't tell if a push event comes from a PR or not.

this means that

1. First, you have to check if the commit is tagged (and so meant for PyPI). If it is, then skip using scm. If it is not

if getenv('IS_COMMIT_TAGGED') == 'false'

then use scm and this commit will get pushed up to TestPyPI. Then build the release with whatever release number scheme you are using. This affects the release number of what is built and so needs to happen first.

2. As every PR will trigger a push event on master then you need to check to make sure that the reference for the push event is actually coming from master

if: github.event_name == 'push' && github.ref == 'refs/heads/master'

3. If the commit is tagged, then push to PyPI. You shouldn't try to check here for the branch as the only information that github.ref can give is the tag, not which branch the tag was coming from.

if: github.event_name == 'push' && startsWith(github.ref, 'refs/tags')

This largely comes from the work @kratsg did on stare. As he points out though, one weakness it that any branch that has a tag pushed to it can trigger a deploy to PyPI. This should ideally be defended against in the future.

[matthewfeickert]

Thank you @kratsg for the fix. Also, thank you for doing all the work already in stare.

[kratsg]

We're safe from malicious PRs: maxheld83/ghactions#262 (comment)