To be relevant with webhooks (as it refers to in actions documentation), I would suggest :

on:
  release:
    actions:
    - published

Because “published”, etc. are refered in an “action” node in webhooks payload.

But I totally agree with the suggestion because currently it triggers 2 runs for each release.

(Btw, thanks for the workaround)

Hi @sidvishnoi,

Thanks for this feedback! We’re always working to improve GitHub, and we consider every suggestion we receive. I’ve logged your feature request in our internal feature request list. Though I can’t guarantee anything or share a timeline for this, I can tell you that it’s been shared with the appropriate teams for consideration.

Awesome! Can’t wait to try it out!

Are you planning on supporting additional filters?

My codebase is a large monorepo. Being able to filter based on release tag would be a huge plus.

Here’s what I’m thinking about:

on:
  release:
    types: [published, created, edited]
    tags:
      - service-a
      - service-b
      - !service-xyz
      - some-other-stuff-v2.*

I hope you get the idea.

I guess you can use the step conditionals to filter by tag value? Not sure. Sorry I’m not a GitHub support engineer.

Perhaps create a new thread?

Filtering on the actual job and/or step is exactly what I’m doing right now. However, since I have a monorepo there are quite a few workflows that get triggered on the “release” event only to be discarded a few moments later.

Here’s an example of the workflow I’m aiming for: Say I have two things (services, packages, …) in my repository that I want to build a package of (Docker, NPM, …), “thing-a” and “thing-b” living in their respective subfolders. When I create a release and tag it with “thing-a@v1.3.9” I want to trigger the build & publish workflow of “thing-a”. I can do this with an “if” filter at the job:

on:
release:
type: [published]
jobs:

build_and_publish:

runs-on: ubuntu-latest

if: github.event_name == 'release' && contains(github.ref, '/thing-a')

steps:

- ...

There is an identical workflow for “thing-b”. Now when I publish a new release both workflows trigger. Workflow “thing-b” is then stopped at  “job.build_and_publish.if” however the triggered workflow appears in the list.

With the new filter system at the workflow overview in place I admit that this is rather an annoyance than a real issue, but since there are similar filters available for the “push” workflow trigger I thought this would make a great addition. And you are right, a new topic would probably make more sense. :slight_smile:

Does anybody know what exactly the difference is between the published, unpublished, created, edited, deleted or prereleased types?

The documentation does not details this.

It’s not easy to find, but it’s documented here: https://docs.github.com/en/free-pro-team@latest/developers/webhooks-and-events/webhook-events-and-payloads#release

on:
  release:
    types: [published, created, edited]
    tags:
      - service-a
      - service-b
      - !service-xyz
      - some-other-stuff-v2.*

This syntax would be awesome for monorepos!
Is there any news if this is going to be implemented? and if not could someway to cancel a action without yielding a error?

I found a way to do this by using the if: on the job.

# This is a basic workflow to help you get started with Actions
name: CI
Controls when the action will run.
on:

release:

types: [created]
A workflow run is made up of one or more jobs that can run sequentially or in parallel
jobs:
This workflow contains a single job called "build"
build-api:

if: startsWith(github.ref, 'refs/tags/api_v.')

This is the solution we have however, it is not as good as allowing some type of filter in the on: clause as it creates builds in the actions list that start and immediately complete as opposed to not listed like actions that are skipped due to the on clause