Github Action trigger on release not working if releases was created by automation?

[Geertvdc]

I’ve been working on some workflows that automatically build & release my application using Github Actions.

i have 2 workflows:

1 build workflow -> this workflow builds my solution and creates some artifacts (zip files). using the Hub cli i create a release and attach these zip files to the release.

source here: https://github.com/XpiritBV/beer-xchange/blob/master/.github/workflows/build.yml

1 release workflow -> this workflow should trigger on a release that is created, download the zip files from the release and deploy them to my environments. however the release trigger is not triggered when the release is created.

source here: https://github.com/XpiritBV/beer-xchange/blob/master/.github/workflows/release-prod.yml

i’ve tried different things to trigger the release workflow with just on: release to defining the types but results are the same. It just doesn’t trigger the workflow.

on:
  release:
    types: [created, published]

When i create a new release by hand instead of using the hub cli it does trigger my workflow. Any ideas how come?

edit: i checked running hub release create by hand and then the release workflow just starts. there is something that if it is triggered inside another workflow that it doesn’t trigger it.

[Geertvdc]

I found the solution with help from @ethomson on twitter. The thing I changed is instead of passing in the default GITHUB_TOKEN you have in your secrets during a workflow I’m using my personal PAT token.

[elucidsoft]

Thank you for this, I feel like this should be a bug…

[nkt]

@github is this expected behavior?

[Geertvdc]

@nkt as you see in my answer @ethomson (who works for Github) mentioned that this is how they designed it (see tweet link above in my answer)

[asgerjensen]

Great. Now just maintain that pr-repo PAT on 400 repos with a max lifetime of one year...

[czerasz]

Suboptimal from the users perspective 🙁

[wvxvw]

Coming from the hell of Jenkins and Gitlab CI, I’ve discovered the new depths of hell I didn’t even think were possible.

This “design” decision is a pinnacle of stupidity.

[johnnyoshika]

Well this is a surprise. For anyone else who’s wondering, I granted the repo permission when generating the personal access token in order to create a release within a GitHub Action:

Screenshot 2022-02-24 212908791×260 11.9 KB

[stefreak]

GitHub prevents workflows from running on events that were caused by other workflows to prevent unlimited recursion (See the docs: Triggering a workflow from a workflow)

If you create a release within a workflow, one alternative to run another workflow after the release has been created is to use the workflow_run trigger. It has a maximum "recursion depth" to prevent unlimited recursion.

Using workflow_run is easier to maintain in the long run than to use personal access tokens to work around this issue.

Note to the GitHub devs: I see that this behaviour makes sense, for example it makes it easier to develop workflows that edit issues and also run when issues are changed. Meanwhile it would be still great if GitHub devs could do something about the user experience here, as I lost a couple of hours today to learn about this behaviour; In the case of automatically created releases this was definitely contra-intuitive for me (and reading the tone in this discussion I am not alone).

[stefreak]

I actually ended up calling a reusable workflow to deploy the software within the workflow that creates the release, instead of using the release trigger. That way I preserved all the information of the original push event in my github context

[warrenackerman]

The workflow_run approach does not allow enough filtering capabilities. It only allows a single condition of sorts. Calling from a job allows for more complex conditions to be met.

[wvxvw]

Yeah, this was exactly my experience with Microsoft support: stupid, uncooperative, will rigmarole you with unhelpful replies until you just give up.

And when the problem is obvious, they will come up with all sorts of imaginary reasons why not fix it. And the reason for this is: support can do nothing about how the product is made, they can only color between the lines of what they were told to do, the R&D don't care, and in most cases have no idea how the product is used or how it could be potentially used.

It's funny that this Github Action thing was supposed to be the "killer feature" that would vendor-lock Github users into using more proprietary Microsoft stuff, but as with all other Microsoft "solutions", it's just so pathetically bad, and reeks of Microsoft from many miles away... It's ironic that no matter how they try, they always get Windows Vista experience.

[stefreak]

If you are referring to my post here, I want to make clear that I am not associated with Microsoft or GitHub at all in any way. I also had the same problem you faced.

Every system has its limitations, some more, some less, but I am absolutely sure that the people at Microsoft are working hard to improve things. It is really hard to change big systems used by millions of people and it can sometimes take a long time. Nobody is smart enough to come up with just the right solutions for every problem from the beginning.

[johnnyoshika]

@wvxvw That's rather harsh. It would be much more productive to give constructive feedback instead of insulting Microsoft. While I don't agree with everything Microsoft does and I was surprised to see that I had to create a personal access token to trigger the on.release.created event, I also appreciate the contributions they make to the open source community and free developer tools. I also understand that I have a choice not use their services if I don't want to and you do as well. You may want to consider exercising that option.

[ringerc]

So ... "on release" doesn't mean "on release", it means "on manually created release".

That's ... er ... special. Because it's already so easy to compose github workflows into sensible, modular units.

See also #16244

[guhcampos]

This is a very unfortunate behavior, as workflow_run does not allow some common use cases. My example:

I'm using the helm/chart-releaser-action to trigger a github release when a chart is modified. It will only trigger a new release if Chart.yaml has a new version. I then expected to run a new post-release workflow with:

on:
  release:
    types: [published]

... which does not work because of this design choice.

Using workflow_run would not work, as the release workflow always runs but does not always trigger a release - my post-release workflow should only run when the release workflow has run and created a release.

I will have to use one of the multiple very dirty workarounds in this case. It does not make it impossible, but rather confusing.

[damianesteban]

Thanks for this, it took me forever to figure out.

[selfdocumentingcode]

I officially hate GitHub actions.