Multiple workflow triggers shouldn't start multiple workflow runs

[aramfe]

Hi,

there is currently an open issue regarding this: https://github.saobby.my.eu.orgmunity/t/how-to-trigger-an-action-on-push-or-pull-request-but-not-both/16662

The problem is basically that if you have multiple workflows triggers defined and these multiple workflow triggers do all meet the requirements, you'll have multiple workflow runs of the very same branch. This might make sense in some cases, but it isn't a very practical way for most other cases. In fact, I can't even imagine a single use case where one would do something like that. So that's questionable as well, but okay.

If it's still not clear what I speak about, I'll try to explain it with some examples:

Well, let's say we have a workflow, where we want to trigger long-running tests only, if a pull request exists, because we otherwise want to save some runner time or simply want to speed up our deployment against some plattform like AWS for normal pushes. Something like this:

on:
  pull-request: 
    branches: master
  push:
    branches-ignore: master
    
    
jobs:
 ...
  run_test:
    if: github.event_name == 'pull_request'
    runs-on: ubuntu-latest
    steps:
 ...

Our expectation was that only one trigger will be executed, i.e. that multiple on statements behave more like this:

if (github.event_name == 'pull_request'): 
    start_workflow_run(with_event='pull_request');
else if (github.event_name == 'push'): 
    start_workflow_run(with_event='push');
else: 
    do_nothing(); 

while in fact it behaves like this:

if (github.event_name == 'pull_request'): 
    start_workflow_run(with_event='pull_request');
if (github.event_name == 'push'): 
    start_workflow_run(with_event='push');
else: 
    do_nothing(); 

I do understand that there might be use cases for behaving as it is behaving right now, but I'm pretty sure that we aren't the only ones, who expect that the first on: triggers requirements should be enough to start a single workflow, without evaluating every following trigger as well. To not have this ability, is pretty annoying and further contributes to the lackluster templating ability GitHub Actions already suffers from, as the only real workaround would be to separate workflow file to separate the triggers - And no, we can't use reusable workflows, as reusable workflows can't use reusable workflows themselves. This is also something that should be supported by the way.

I do propose the addition of a functionality to achieve the behaviour we actually expected. Maybe a single option like only_one_condition: true or some if-statements. Not sure, there are plenty ways to achieve that.

I'm pretty sure this should be fairly easy to implement as it's just some syntax + interpreter addition, without changing the underlying system.

[ethomson]

If I'm understanding correctly, you have a CI system that you want to run during development, so that any time a user pushes a feature branch update, they'll get the minimal CI. And then when they open a pull request from that feature branch, they would get the more advanced CI on the pull request (but no longer run the original CI on those branches).

Our expectation was that only one trigger will be executed, i.e. that multiple on statements behave more like this:

if (github.event_name == 'pull_request'): 
    start_workflow_run(with_event='pull_request');
else if (github.event_name == 'push'): 
    start_workflow_run(with_event='push');
else: 
    do_nothing(); 

That's right - this is how trigger matching works. What's happening right now is not that a single event is triggering two workflows - these are two distinct events. You're pushing to a branch, so you get an event that a branch was pushed to. Since your PR branch was updated by that push, you will also get a pull request synchronized event. (As a result, this is not an easy change.)

I appreciate the feedback, though. We'll add this to the backlog to consider how we could improve this specific use case.

I would imagine that there may be some workarounds that you could explore, though it might require additional information about your workflow - I'm not used to seeing a workflow that . For example, are these normal development branches as users iterate? Or are they long-lived "feature" branches? I think that the GitHub Actions support community would be useful to explore some options.

Thanks for the feedback!

[aramfe]

Thanks for your reply and you're right. I had a misconception here. It's not as easy as expected.

So yes, I think it needs to be better defined of what I actually want: It's basically an automatic cancel of other workflow run for the very same user input, without handling each event for its own. Basically a way to aggregate multiple events for a specific workflow, which are triggered in the very same second because of the very same user input, as one single event and with that to run only one single workflow.

There is in fact a way to achieve this very intended behavior, by canceling a previous run workflow with the concurrency options. I'm just not a big fan of this, as this basically leads to a summary overview with a lot of unnecessary cancelled workflow runs. If there would be a way to automatically delete these runs, then I would be happy to work with that.

[ethomson]

Thanks for the reply - I agree that cancellation is an effective but rather inelegant workaround. We'll take a look at how we can improve this for you in the future. Thanks again.

[h2floh]

Didn't thought it through end2end but maybe concurrency option could help here. This allows To also cancel any currently running job or workflow in the same concurrency group, specify cancel-in-progress: true. Maybe there is a way to associate/define the concurrency-group with the same event inputs you are mentioning.

[jsoref]

Fwiw, this is how check-spelling action handles this:
https://github.com/check-spelling/check-spelling/blob/cb7b743c240a74786679a4de908dbe5b013984ce/unknown-words.sh#L34-L60

It took me quite a bit of effort to reach this code, and I'm moderately happy with it, although I'd prefer not to have to have it at all.

[Juanito87]

Ideally, we have a stage were we can evaluate all the event and define an action.
Defining a variable to enable this like evaluate_events, and if not, by default run all the triggers of the workflow.
If variable is defined, we can apply the logic:

f (github.event_name == 'pull_request'): 
    start_workflow_run(with_event='pull_request');
else if (github.event_name == 'push'): 
    start_workflow_run(with_event='push');
else: 
    do_nothing(); 

[vinaydevopss]

You said:
I have two github workflow file in my folder. while triggering one workflow with github issue other workflow is also running but it skipped , how to fix this issue and need to run only one workflow job related to issue created