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.

3 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:

1 Like

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

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

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.')
1 Like

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