Feature Request |trigger action on "Pull Request Approved" #25372

alexhraber · 2020-05-13T09:14:41Z

alexhraber
May 13, 2020

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.

Screen Shot 2020-05-13 at 1.55.52 AM.png736×356 19.5 KB

Screen Shot 2020-05-13 at 1.56.12 AM.png746×368 20.6 KB

Screen Shot 2020-05-13 at 1.57.38 AM.png772×1258 50 KB

cc @chrispat @github-staff

Answered by weide-zhou

May 14, 2020

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.

on:
  pull_request_review:
    types: [submitted]
jobs:

build:

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.

Cheers!

View full answer

alexhraber · 2020-05-13T10:49:22Z

alexhraber
May 13, 2020
Author

A native solution was found:
https://github.community/t5/GitHub-Actions/GitHub-Actions-Manual-Trigger-Approvals/m-p/58137/highlight/true#M10446

Having this a first class citizen is still recommended.

0 replies

weide-zhou · 2020-05-14T02:24:15Z

weide-zhou
May 14, 2020

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.

on:
  pull_request_review:
    types: [submitted]
jobs:

build:

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.

Cheers!

6 replies

niall-shaw Jan 24, 2023

@weide-zhou - please can you provide an insight as to whether the team is looking into this, as the noise is really offputting

ADTC Mar 26, 2023

@FrostDNA @niall-shaw try using delete-workflow-runs v2 with the following config example to clean up the skipped runs. It runs once a day. You can also run it manually by going to the Actions tab, opening it and clicking Run workflow (any branch).

See Gist for example. Uncomment the dry_run line to test it.

Edit: To clarify here, I'm NOT trying to solve the original problem.

I'm just helping people by sharing a workaround. If this really bothers you so much, you can set the cron job to run every hour, every 10 minutes, or every minute - effectively you will not see much of it. But asking me why I'm not implementing the option, then 👎ing me for it is like asking some random person on the street why he didn't pass a bill into law in the government, then beating him up for it. It's hateful bigotry: negative, dismissive, thankless, rude, idiotic and moronic.

And for fk's sake, most of you are using GitHub for FREE. Do you think you're entitled with a right to demand they do what you want?

Be nice.

FrostDNA Mar 27, 2023

Hello @ADTC, this solution is solving the consequence not a root cause of whole problem. Why it's a problem to implement one more option: pull_request: [approved]???

ADTC Mar 27, 2023

Hello @ADTC, this solution is solving the consequence not a root cause of whole problem. Why it's a problem to implement one more option: pull_request: [approved]???

@FrostDNA because I don't work for GitHub. That's the problem. F👎 me for trying to help you, right?

FrostDNA Mar 27, 2023

Oh, sorry :) I thought you work there. My apologies :)

ollisala · 2020-06-09T04:10:40Z

ollisala
Jun 9, 2020

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.

0 replies

pantelis-karamolegkos · 2022-08-05T08:29:59Z

pantelis-karamolegkos
Aug 5, 2022

This would be very helpful because adding the custom check on jobs if: github.event.review.state == 'approved' makes the Actions tab noisy

2 replies

FrostDNA Oct 31, 2022

So true look at my comment https://github.com/orgs/community/discussions/25372#discussioncomment-3982987

ADTC Mar 26, 2023

@pantelis-karamolegkos See my comment for a possible solution to the clean up the noise: https://github.com/orgs/community/discussions/25372#discussioncomment-5432089

tassilo-posegga · 2023-07-05T13:34:05Z

tassilo-posegga
Jul 5, 2023

Adding to this: It looks like concurrent jobs are canceled if people leave a review which seems to trigger another run. Following scenario:

PR gets approved - our ling lasting UI test workflow kicks off
10 min into the workflow someone else leaves a comment on the PR - the previous jobs get canceled

concurrency:
  group: gherkinTests-${{ github.ref }}
  cancel-in-progress: true

I assume a workaround would be to also include the state into the concurrency group

I am looking for a STABLE solution to trigger all our checks once the LAST NECESSARY approval was added to a PR. In our case that would be the second approval

0 replies

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

GitHub Community

Feature Request |trigger action on "Pull Request Approved" #25372

{{title}}

Replies: 5 comments 8 replies

{{title}}

{{title}}

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

Be nice.

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

Select a reply

Feature Request |trigger action on "Pull Request Approved" #25372

Replies: 5 comments · 8 replies

alexhraber May 13, 2020 Author

Edit: To clarify here, I'm NOT trying to solve the original problem.

Be nice.

Replies: 5 comments 8 replies

alexhraber
May 13, 2020
Author