GitHub Community
-
|
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. 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 |
Beta Was this translation helpful? Give feedback.
Replies: 13 comments 4 replies
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for this, I feel like this should be a bug… |
Beta Was this translation helpful? Give feedback.
-
|
@github is this expected behavior? |
Beta Was this translation helpful? Give feedback.
-
|
@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) |
Beta Was this translation helpful? Give feedback.
-
|
Great. Now just maintain that pr-repo PAT on 400 repos with a max lifetime of one year... |
Beta Was this translation helpful? Give feedback.
-
|
Suboptimal from the users perspective 🙁 |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
Well this is a surprise. For anyone else who’s wondering, I granted the |
Beta Was this translation helpful? Give feedback.
-
|
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 Using 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). |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
@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. |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
This is a very unfortunate behavior, as 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 ... which does not work because of this design choice. Using I will have to use one of the multiple very dirty workarounds in this case. It does not make it impossible, but rather confusing. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for this, it took me forever to figure out. |
Beta Was this translation helpful? Give feedback.
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.