Add support "approved" for PR_READY_STATE

[sebastianludwig]

While working in a high throughput repository we want to keep our CI load down and only auto-update the PRs once everybody is happy with them. There's no need to have GitHub update the PRs and the CI build them while a developer is still working on them and addressing the feedback. We'd like to use the auto-update to help working through our "waiting to be merged" queue.

Is it possible to add an "approved" condition to PR_READY_STATE which evaluates to true once all required reviewers have approved a PR?

[chinthakagodawita]

Hey @sebastianludwig - unfortunately, this isn't as simple as #233.

What constitutes "approved" is going to be different from repo-to-repo and there's nothing in the Github pull request API that exposes this information. This would require loading each review on the PR, checking its status and comparing the number of approvals against some (new) autoupdate configuration value. This would significantly increase the complexity of this action and it isn't something I'm that keen on adding at the moment.

I'm planning a larger architectural refactor of how conditions/filters work and this may need to wait till then.

In the meantime, I'd recommend a workaround using labels:

• Use an action to add a label (e.g. autoupdate) once your PRs hit a certain number of approvals, e.g.
  • https://github.com/abinoda/label-when-approved-action
  • https://github.com/tiangolo/label-approved
  • https://github.com/TobKed/label-when-approved-action
• Configure autoupdate with PR_FILTER=labelled and PR_LABELS=autoupdate

[lone-cloud]

This workaround doesn't work consistently. I believe the missing part is to also change autoupdate's workflow:

on:
  push: {}
  workflow_run:
    workflows: ['label-approved']
    types:
      - completed

[mrchief]

You can have the PR in draft state and exclude it from autoupdate via PR_READY_STATE: ready_for_review, no?

[ureciocais]

@chinthakagodawita now Github exposes that information. An example of accessing it in a workflow is: github.event.review.state. That variable can be "approved". Another one is the reviewDecision using gh. I.e: gh pr list --json reviewDecision --jq '.[] | select(.reviewDecision == "APPROVED")' And yet another one is via their Graphql API. I'm afraid REST is still a bit behind... I would be happy to put up a PR if you are ok with that