We've noticed that the same reviewer approving, re-requesting review and approving again counts as two approves.
This could be avoided in the code.

I have installed the action in accordance with the README.md, such that I have 3 labels:
label a requires 0 reviews
label b requires 1 reviews
label c requires 2 reviews

Steps to reproduce the unexpected behavior:

1. I open a PR with some changes
2. I add the b label (such that 1 review is required)
3. the check (titled pull_request) fails (expectedly, since there are no reviews) and I cannot merge
4. Someone else approves my PR
5. A new check (titled pull_request_review) succeeds (due to the approval) but the previous pull_request check is still present and failed and I still cannot merge

Is it possible to fix this (without manually re-running the checks)?

# This workflow will set a number or reviewers depending on the labels
name: Label Reviews
# Trigger the workflow on pull requests
on:
  pull_request:
    types:
      - opened
      - reopened
      - synchronize
      - labeled
      - unlabeled
  pull_request_review:
    types:
      - submitted
      - edited
      - dismissed
jobs:
  require-reviewers:
    # Optional: skip check if no relevant label is present
    # This needs to be kept in sync with the labels being checked
    runs-on: ubuntu-latest
    steps:
      - name: Require-reviewers
        uses: travelperk/[email protected]
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        with:
          rules_yaml: | # define which PR labels require how many aprroving reviewers
            a: 0
            b: 1
            c: 2

I have a scenario wherein branch usage prevents the branch protection rule "Require pull request reviews before merging". However, the check is still needed on pull requests going into the branch mentioned.
ie:

• master
• epic/some-epic
• feature/some-feature

In the above, feature/some-feature is to merge into epic/some-epic but, epic branch rules do not and cannot enforce "Require pull request reviews before merging" as this prevents developers from updating epic branches with "master" without a PR.
In addition to this, the check does not dismiss outdated reviews which is desirable but, not possible without the PR requirement rule.

So, can functionality be added such that:

1. the branch protection rule is not required
2. a mechanism to fake dismissal of outdated reviews (approvals)

• ie: the approval count tracking approvals is reset if the approval timestamp is after the most recent commit

One of the main use cases for this action is updating then reviews for an existing PR are posted. Currently the PR info can't be retrieved on the entrypoint code and the workflow is failing when this happens.

Node 12 has been out of support for some time and there are some security concerns in my org for using a tool on an old runtime that isn't seeing security patches.

https://github.blog/changelog/2022-09-22-github-actions-all-actions-will-begin-running-on-node16-instead-of-node12/

As mentioned on #1 there is still a lack of test for the main entrypoint workflow.