Add independent peer review validation workflow

.github/workflows/verifyPeerReview.yml

@@ -0,0 +1,52 @@
+# Note: This workflow is configured to run on all pull requests throughout the Expensify org, not just this repo.
+# That has a few consequences:
+#    - We need to checkout the repo it's running on, and not just the GitHub-Actions repo
+#    - branch and path matching does not work in the workflow layer. From the docs: https://docs.github.com/en/enterprise-cloud@latest/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/available-rules-for-rulesets#supported-event-triggers
+#        > Any filters you specify for the supported events are ignored - for example, branches, branches-ignore, paths, types and so on. The workflow is only triggered, and is always triggered, by the default activity types of the supported events
+name: Verify peer review
+run-name: Verify peer review for ${{ github.repository }}#${{ github.event.pull_request.number }}
+
+on: pull_request
+
+permissions:
+  contents: read
+  pull-requests: read
+
+jobs:
+  verifyPeerReview:
+    name: Check independent approval
+    runs-on: blacksmith-2vcpu-ubuntu-2404
+    steps:
+      # v3.1.1
+      - name: Generate a GitHub App token
+        id: generateAppToken
+        uses: actions/create-github-app-token@1b10c78c7865c340bc4f6099eb2f838309f1e8c3
+        with:
+          app-id: '179547'
+          private-key: ${{ secrets.MELVIN_APP_PRIVATE_KEY }}
+          owner: ${{ github.repository_owner }}
+          repositories: |
+            ${{ github.event.repository.name }}
+            GitHub-Actions
+          permission-contents: read
+          permission-members: read
+          permission-metadata: read
+          permission-pull-requests: read
+
+      - name: Checkout repos
+        id: repo
+        uses: Expensify/GitHub-Actions/checkoutRepoAndGitHubActions@main
+
+      # v4.3.0
+      - name: Setup Node
+        uses: actions/setup-node@cdca7365b2dadb8aad0a33bc7601856ffabcc48e
+
+      - name: Install npm packages
+        run: npm ci
+        working-directory: GitHub-Actions
+
+      - name: Verify peer review
+        run: npm run verify-peer-review
+        working-directory: GitHub-Actions
+        env:
+          GITHUB_TOKEN: ${{ steps.generateAppToken.outputs.token }}

README.md

@@ -37,6 +37,12 @@ jobs:
     secrets: inherit
 ```
 
+### `verifyPeerReview.yml`
+
+Used as an org-level ruleset workflow to block pull requests that do not have enough independent Expensify employee approvals. The check only reads GitHub pull request metadata; it does not checkout or execute code from the pull request branch.
+
+This workflow requires a GitHub App token with read access for repository metadata, pull requests, and organization members. It uses the Melvin Bot app ID `179547` and `MELVIN_APP_PRIVATE_KEY` to generate that token. If GitHub does not return a branch-protection review count, the workflow defaults to requiring one independent approval, so the ruleset should target only the intended protected branches.
+
 ## Rulesets
 GitHub [org-level rulesets](https://docs.github.com/en/enterprise-cloud@latest/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/available-rules-for-rulesets#require-workflows-to-pass-before-merging) can be configured to run a workflow check against pull requests in all repos in the org. This is a very powerful feature, but there are some caveats and best practices to be aware of when enabling a ruleset.
 
@@ -47,3 +53,4 @@ GitHub [org-level rulesets](https://docs.github.com/en/enterprise-cloud@latest/r
     - If you need to target or exclude specific paths, that must be implemented manually in the workflow itself.
 - Due to a GitHub :bug:, PRs that are open when the rule is enabled will get stuck with a pending check that will never get picked up. The easiest way to fix that is to close and reopen the PR. Consider writing a script to close and reopen all open PRs across the org after the check is enabled.
 - It is less disruptive to [configure the ruleset to `Evaluate` first](https://docs.github.com/en/enterprise-cloud@latest/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/available-rules-for-rulesets#using-evaluate-mode-for-ruleset-workflows), then `Active` once the kinks are worked out.
+- For `verifyPeerReview.yml`, start with a ruleset targeting only a test branch, then test the workflow from a GitHub-Actions branch, then from `main`, and only then enable it for the intended repositories and branches.