Feature Request |trigger action on "Pull Request Approved"

I have a workflow that I have completely built out, only to find out that the actions api doesn’t support “pull-request: approved” (or some variant).

Based on this thread, it seems this is a feature many folks want: https://github.community/t5/GitHub-Actions/GitHub-Actions-Manual-Trigger-Approvals/td-p/31504/highlight/false

None of the current Acivity Types are practical for my use case, and I’m suprised the “approved” activity type is not already supported.

My workflow:

Submit PR -> build triggers -> upon completion a reviewer approves -> upon approval a new action fires off -> merge.

This is very useful for many things, and makes automation simpler. For example – I may want to notify my team in slack that I am merging… I obviously wouldn’t notify before the PR has been aproved.

Well my use case is quite a bit more complex than updating slack – but that is the basic idea. A PR has been approved, and that is a basic GitHub activity that is essential to every developer’s workflow.

Nothing else in the list below will work.

I don’t want our devs typing some magical comment to get things to work, with special regex cases to match every possibility. Same for labels etc.

And the principal idea is “automation”. There are modules to update comments and labels – but what triggers that automatically on approval (which is when we need the action to fire)? The ‘approval action type’ would.

cc @chrispat @github-staff 

1 Like

A native solution was found:

Having this a first class citizen is still recommended.

Hi @everops-alex ,

Thanks for your sharing. The native solution you provided works perfectly(trigger with ‘pull_request_review: submitted’ event and check ‘github.event.review.state’ value if it’s ‘approved’)! 

And it’s recommended to check the value in job level within if expression, it will skip unneccessary jobs to be started.

    types: [submitted]

    if: github.event.review.state == 'approved'
    runs-on: ubuntu-latest
steps: ...

Regarding the first class citizen feature_request, please raise a ticket here according to the policy, github product manager will take a review and help to confirm.


1 Like

This workaround seems not to work if you want have multiple different workflows. I’m deploying to two environments with different yml-files from branches test and master. In following situation it bugs:

If pull request is done for example against test-branch and someone reviews it, deployment starts also towards another environment (which is integrated to master branch) although in that yml-file there is no mention about test-branch.