GitHub Actions: Filter on release

Currently, on:release doesn’t support any filters (for example, on:pull_request supports branches filter). Would be nice if something like following gets supported:

on:
  release:
    events:
    - published

As a workaround, I’ve to do the following, which leads to one failed build and one successful build on every published release:

on: release
jobs:
  publish:
    steps:
      - name: Cancel if not a release publish # workaround has `on` doesn't have this filter
        run: exit 1
        if: github.event.action != 'published'
      - uses: actions/checkout@v1
2 Likes

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)

1 Like

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.

1 Like

You can now filter the release event using types, for example:

on:
  release:
    types: [published]

More info: https://help.github.com/en/articles/workflow-syntax-for-github-actions#onevent_nametypes

3 Likes

Awesome! Can’t wait to try it out!

1 Like

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.

2 Likes

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.

1 Like