Prevent deployment of pre-releases

[2ndkauboy]

trafficstars

Is your enhancement related to a problem? Please describe. When developing a plugin on GitHub, it's not uncommon to tag pre-releases (like beta and release candidates). Those tags would also trigger a deployment on the plugin directory.

Describe the solution you'd like The action currently runs on all tags. With a simple addition, which excludes all tags with a suffix (e.g. 2.0.0-beta, 2.0.0-RC1, etc.) such pre-release tags would not trigger the action.

name: Deploy to WordPress.org
on:
  push:
    tags:
    - "*"
    - "!*-*"
...

Additional context This change can be done without chaning the files of the actions, it should only be added to the README of this repo.

[helen]

Do you typically do these tags on master or do you tag on a development branch? Some people do deploy these to .org, FWIW :) We can certainly add more examples, I'd just love to know more about what you're doing as we develop these.

[2ndkauboy]

I think the way GitHub actions work, there is no difference if you create a tag on master or any other branch.

I personally don't tags/publish pre-releases, but for some plugins I help to maintain, we use pre-release tags. We usually do them on master.

[helen]

I'm actually not sure about the tag+branch filtering? I suppose a tag is not technically pushed to a branch but I do wonder if they can somehow be combined in the way GitHub is using them, since a tag does know which branch that tagged commit was on. In any case, if it's all being done on master that doesn't change anything. Does it make sense to keep adding examples to the readme or would it be better to have a separate reference?

[2ndkauboy]

I would just add an example to the readme. Either with this as an addition/alternative or by just explaining the new line.

[helen]

Copying my comment to @sc0ttkclark over here:

I am worried about exactly what you experienced, which is that as people are getting these things set up for the first time, they won't quite understand that they may need to remove stuff from the sample workflow file, so maybe it should be a barebones example and link off to more examples in a separate document.

[danieliser]

@2ndkauboy - Simply update your action script. This is ours using semver.

It works with v1.0.0, but not with v1.1.0-alpha.1 or v2.0-beta.3 etc

name: Deploy to WordPress.org
on:
  push:
    tags:
    - 'v*'
    - '!v*-alpha*'
    - '!v*-beta*'
    - '!v*-rc*'

This works, but there is also tags-ignore

name: Deploy to WordPress.org
on:
  push:
    tags-ignore:
    - 'v*-alpha*'
    - 'v*-beta*'
    - 'v*-rc*'

Documented here: https://help.github.com/en/actions/reference/workflow-syntax-for-github-actions#onpushpull_requestbranchestags

[johnbillion]

Another option is to use the release event instead of push.tags and then the workflow will only fire when you publish the release on GitHub. The published type will only fire for published, non-prerelease releases.

on:
  release:
    types: [released]

Edit: Changed the above to released instead of published.

[GaryJones]

The published type will only fire for published, non-prerelease releases.

That's not the case according to https://docs.github.com/en/actions/learn-github-actions/events-that-trigger-workflows#release (my emphasis):

If you want a workflow to run when stable and pre-releases publish, subscribe to published instead of released and prereleased.

[jeffpaul]

@GaryJones nice catch! Adding a task here for us to document that:

• [ ] add note to readme about different release types to list based on how a specific plugin handles releases (including stable and pre-releases)