You can use if: github.event.review.state == 'approved' along with
your other condition.
Actually, this suggestion from LeadingMoominExpert is part of a possible solution.
Tests
I tried this implementation using the pull_request: types: [labeled] as suggested on the question from Dan Cook and it wasn't working.
The problem is because the pull_request labeled event doesn't have the github.event.review.state field filled on the $GITHUB_CONTEXT when this event occurs, therefore the value will be null and the condition will return false.
To make it works, I had to change the workflow trigger on condition to pull_request_review: types: [submitted] instead of pull_request: types: [labeled].
But the behavior isn't exactly the same as expected.
In that case, the event will trigger only when someone submit a review, and if the pull request state is approved, and already has the expected label, then the workflow's job will be executed.
To check the behavior of each event you can try this implementation
name: PR approved and labeled
on:
pull_request:
types: [labeled]
pull_request_review:
types: [submitted]
jobs:
build:
runs-on: ubuntu-latest
if: ${{ (github.event.review.state == 'approved') && (contains(github.event.pull_request.labels.*.name, 'test')) }}
steps:
- name: Dump GitHub context
env:
GITHUB_CONTEXT: ${{ toJSON(github) }}
run: echo "$GITHUB_CONTEXT"
- run: echo ${{ github.event.review.state }}
You'll see that adding a label (in that case, containing test) won't execute the job, but submitting a review approving this PR, with the expected label set, will run it.
Conclusion
Dan, what you want to achieve isn't possible (yet?) using the pull_request: types: [labeled] event.
The example above is a workaround, but that may not attend exactly what you expect.