Unintentional workflow triggers

[rpanderson]

The workflow in .github/workflows/release.yml begins:

on:
  push:
    branches:
      - master
      - stable
  create:
    tags:
      - 'v[0-9]+.[0-9]+.[0-9]+*'

This was intended to trigger off either:

• push to master or stable branches
• creation of semver-compliant tags prefixed by v.

Evidently (and unintentionally), I think this workflow also triggers off:
1 Creation of any branch (implicit in above create block)?
2. Creation of tags not beginning with v.

Evidence for these are in the following workflow runs, respectively:

1. Run 658794923. Output of the 'Github Properties' job was:

github.ref: refs/heads/stable
github.event_name: create
github.event: Object
github.event.name:
github.event.ref: stable
github.event.ref_type: branch
github.event.master_branch: master
github.actor: rpanderson

2. Run 658794896. Output of the 'Github Properties' job was:

github.ref: refs/tags/0.1.1
github.event_name: create
github.event: Object
github.event.name:
github.event.ref: 0.1.1
github.event.ref_type: tag
github.event.master_branch: master
github.actor: rpanderson

The first of these is unexpected but easy to fix, by:

• Adding a conditional failure to the github_properties job, which filters out branch creation; and
• Making the release job dependent on this using needs: github_properties.

The second one is odd, and would seem to be a bug or incorrect usage of the tag filter.

Aside

The reason I'm including create events in this workflow is that they have nicer properties for unambiguously introspecting tags and versions from. Here's a table of examples for different events:

Property	Push (branch)	Push (tag)	Create (branch)	Create (tag)
github.ref	refs/heads/master	refs/tags/v0.1.0rc7	refs/heads/stable	refs/tags/v0.1.0rc7
github.event_name	push	push	create	create
github.event	Object	Object	Object	Object
github.event.name
github.event.ref	refs/heads/master	refs/tags/v0.1.0rc7	stable	v0.1.0rc8
github.event.ref_type			branch	tag
github.event.master_branch	master	master	master	master
github.actor	rpanderson	rpanderson	rpanderson	rpanderson

Note:

• github.ref and github.event.ref are the same for push events, regardless of tag or branch pushes.
• github.event.ref_type is unpopulated for push events.
• The least ambiguous reference to the tag is github.event.ref of github.event_name == create and github.event.ref_type == tag.

[rpanderson]

See:

• GitHub Actions / Reference / Events that trigger workflows
• Stackoverflow: Which properties does github.event in a GitHub Workflow have?
  
• GitHub Community Forum: How to get just the tag name?

[rpanderson]

Note: I have since deleted tag 0.1.1.

[philipstarkey]

This just bit me (because I haven't been following these issues)! Is it possible that pushing a non-compliant tag still triggers the workflow because it is considered a push to master?

Rather than filtering which steps of the release job run using if: github.event.ref_type == 'tag', could we instead have that if statement check if the format of the tag matches our expected format?

[chrisjbillington]

Pushes to master are supposed to trigger the workflow still, but just to skip the uploading to non-test PyPI and the main anaconda label.

[philipstarkey]

I understand that, my point was (which maybe you got anyway?) that Russ's unexpected behaviour listed in point 2 in his first post might be explained by the tag not matching (as expected), but the workflow still runs because it matches the other condition (if pushing a tag by itself is considered pushing to master) rather than the tag matching not working correctly.

[chrisjbillington]

Right, I see. Not sure that's the case, but I think I understand what you're saying.