Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Get approval status in GitHub action

I have an action that fires when a label is added.

pull_request: types: [labeled]

The job should run conditionally, only if the pull-request is approved (there is one or more approval) as well as another condition which is working fine:

jobs:
  build:
    if: ${{ (something == 'approved') && (contains(github.event.pull_request.labels.*.name, 'Deployed for QA')) }}

What property can I use in place of 'something' in the condition above?

like image 274
Dan Cook Avatar asked Oct 08 '21 09:10

Dan Cook


People also ask

How do I know if GitHub PR is approved?

The link help.github.com/articles/… shows that, using reviews the reviewer can request for changes which is giving a indication that the PR is rejected for changes.

How do I add approval steps in GitHub actions?

To approve the job, click Approve and deploy. Once a job is approved (and any other environment protection rules have passed), the job will proceed. At this point, the job can access any secrets stored in the environment. To reject the job, click Reject.

Why do people on GitHub free want an approval step?

So people on GitHub Free who want an approval step in their workflow are basically being told to suddenly start paying a LOT more just to have that feature (since pricing is per user, not per account), or to give up on GitHub Actions altogether and either spin up a Jenkins server for their CI/CD, or move version control and CI/CD to GitLab.

How do I add manual approval requirements to GitHub workflows?

Now we can add manual approval requirements to our workflows through GitHub’s new Environments configurations. Environments also support environment specific secrets in additional to repository-wide secrets. To demo environments and approvals I’ve created a simple .net web app, along with two Azure Web Apps (dev and prod).

How do I create an environment in GitHub actions?

From your GitHub repo access Settings, and you should now see Environments in the left menu. Click New environment, provide a name, and click Configure environment. Note: If you target an environment name in your GitHub Actions workflow file and that environment name does not exist GitHub will automatically create it for you.

What is the approval duration for a manual approval action?

Note: This approval duration is subject to the broader 72 hours timeout for a workflow. So keep that in mind when figuring out how quickly an approver must respond. Workflow comes to the manual-approval action.


2 Answers

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.

like image 165
GuiFalourd Avatar answered Oct 23 '22 11:10

GuiFalourd


You can use if: github.event.review.state == 'approved' along with your other condition.

like image 1
LeadingMoominExpert Avatar answered Oct 23 '22 13:10

LeadingMoominExpert