Ah, I see, thanks a lot. I played a little with the if conditional and this works pretty well. It looks like that the job produces a “fail” if the condition is not met, right? This would give me an error message/email… I could add the conditional to each step and get rid of that, but this seems less obvious. Is the described behavior expected and intended?

Btw. I found another way to test for any given label (since I now knew where to look thanks to your reply):

jobs:
  job01:
     if: contains( toJson(github), '<label_name>' )

Don’t know if that is a good idea (since it could find <label_name> somewhere else in the issue data), but so far it works.

Yeah, in the past, if all jobs in a workflow were skipped with the if conditional , the workflow displayed as “skipped/no status” status with a grey icon. But now, it displays as failed and will send the notification email for the failed workflow run.

This is a great solution ! We are using this but now if shows a failed workflow instead of just not running it. Do you have a workaround ?

add a empty step that just echo some dummy text.

Edit: Sorry I haven’t seen the date.

Hey. I searched for a while, but did not found any solution.

Is it possible to check if the label was set by some specific account or even better by the codeowner(s)?

This is really disappointing - not being able to limit a workflow from running ends up polluting the list of ran actions pretty dramatically, because even if you conditionalize a job it will still show up in the list of actions just with a gray cross over it indicating it didn’t run.

This is exceptionally problematic when conditionally running a large number of actions.

Just to save someone else some time:
Scenario is that I only want to trigger a lint job if the file changed is of a specific extension(our case is golang). The workflow should only trigger if the PR is approved.

Problem 1

As described here

The ON trigger conditions work as OR and not as AND. Therefore, in the question sample, the workflow will trigger when a pull_request_review is submitted OR when one of the updated file(s) path is the one informed.

So using path in

on:
  pull_request_review:
    branches:
      - main
    types: [submitted]

is out of the question unfortunately. BTW the code over at this example won't work either for all file types changed, the correct glob syntax will be **.*.go, but the path keyword will be evaluated.

We're getting around this by using the labeler action.

The lint workflow now looks something like:

.....
jobs:
  lint:
    # the ON keyword is ANY not AND for conditions regarding path. Need to work around with labelling for PRs. 
    if: contains(github.event.pull_request.labels.*.name, 'golang') && github.event.review.state == 'approved'
.....

Problem 2

There's a major difference between how pull_request and pull_request_review events are defined.
github.event.label.name == 'project' will work for event type pull_request BUT the real unexpected case happens when you open PR's that for example change files with the .md extension:

the workflow will also trigger for those if at any point in time there was a PR with the golang label opened on the repo!!!!

I bashed my head against this for about an hour trying to figure out how it's evaluating to true, and with some trial and error found that with @lmancilla 's original suggestion of if: contains(github.event.pull_request.labels.*.name, 'some-defined-label') works as expected.

TLDR

Be mindful of which exact pull_request event type you're referencing because the event object structure is different. Use github.event.label.name == 'project' for pull_request triggers use contains(github.event.pull_request.labels.*.name, 'some-defined-label') for pull_request_review.