Pull requests

The Pull Requests page (/app/pull-requests, Pull requests in the sidebar) lists the pull requests Prodgator gates and their policy results. It needs no separate setup beyond binding a policy to pull requests. The sidebar item shows how many open pull requests have a failing Prodgator check.

What it listsCopy Anchor Link

Three tabs: Open, Merged and Closed. Open shows every open pull request from a repository with the GitHub App installed. Merged and Closed show pull requests closed in the last 30 days, or fewer if your plan's data retention is shorter than that.

Next to the tabs, Unprotected narrows any tab to pull requests whose repository does not require the Prodgator Policies check: the ones the Protected column marks as not required. Its count is how many there are with the other filters applied. It stays on while you switch tabs, and it is part of the page link, like the other filters. A repository counts once the page has read its merge protection (the Protected column does this as you browse); one nobody has looked at for a week is left out until it is read again.

ColumnsCopy Anchor Link

• Pull request: the number and title, linking to the pull request on GitHub, with the repository underneath and a Draft or Fork tag when either applies.

• Author: who opened it.

• Branch: the head branch merging into the base branch.

• Prodgator: a Policies chip with the latest Prodgator Policies check result (Passing, Failing, Waiting, Overridden, Observe only or Not gated), and a Compliance chip when a blocking compliance policy has reported. On a narrow screen the chips show their icon only; hover one for its full status.

• Protected: an icon for whether GitHub requires the Prodgator Policies check on the pull request's base branch: required, not required, or unknown (GitHub did not answer, or the pull request targets a branch other than the default branch, the only one Prodgator reads). Hover it, or expand the row, for details. Pull requests no policy governs show a dash.

• Reviews: how many GitHub reviews approved it, and whether changes were requested.

• CI: how many checks passed, failed and are still running.

• Security: critical and high severity findings the change introduces, for pull requests governed by a policy with a security rule, custom rules or Rego.

• Attestations: of the attestations run reports sent for the pull request's head commit, how many passed out of those that passed or failed (coverage and other informational ones are not counted).

• Labels: the pull request's GitHub labels.

• Age: how long it has been open, or how long ago it merged or closed.

• Updated: when it last changed.

Security, Attestations and Labels show only when at least one pull request on the page has a value for them; the expanded row shows them for that pull request either way.

FiltersCopy Anchor Link

Search by title, number, repository, branch or author, or narrow by Repository, Author, Prodgator status and Base branch. Each filter menu shows how many pull requests match each value, counted against every other filter you have set. Filters and the tab live in the page's URL, so a filtered view is a link you can share.

The expanded rowCopy Anchor Link

Click a row, or its details arrow, to open it in place. It shows:

• A header with the evaluation's result, when it ran, on which commit, and whether it ran for the pull request itself or a merge queue group, links to the pull request and the check run on GitHub, and Re-evaluate and View input for editors.
• Policy results: each policy that applies, its mode (Enforce or Observe) and its result, then one row per rule with its status (Pass, Fail, Waiting or Error), whether it is Blocking or Advisory, and its reason. Failing and blocking rules come first, in the same order the GitHub check text uses. Rules link to their evidence on GitHub or on the pipeline run report where one exists. Any error the evaluation hit reading GitHub follows, explained in plain language.
• Prodgator approvals, inside the row of the Prodgator approvers rule that reads them: everyone's latest decision, with a note when it was given on an older commit than the one now being checked, and the Approve, Reject and Withdraw my decision buttons.
• History, next to the policy results on wide screens: the last 10 evaluations, each selectable to see that evaluation's own results.
• Security: the critical, high, medium and low findings the change introduces, or a line saying it was not read when no policy on the pull request has a security rule, custom rules or Rego.
• Labels: the pull request's GitHub labels, or No labels.
• Attestations: each attestation run reports sent for the pull request's head commit (the newest from each job): its status (Pass, Fail, Warning or Info), name and kind, a one-line summary such as test or scan counts, the job and attempt it came from (linking to the pipeline run), and when it arrived.
• Merge protection on GitHub: whether GitHub requires the Prodgator Policies check on the repository's default branch, where the requirement comes from, a button to check again, and when it is not required, how to require it (see Set up).

A pull request linked from the check run's Details link (or a ?pr= link) opens already expanded, even when it sits on another page of the list or another tab.

What editors and admins can doCopy Anchor Link

• Editors and admins can click Re-evaluate to ask Prodgator to check the pull request again right away, past the usual debounce. It is disabled, with a tooltip, once the pull request is closed.
• Editors and admins can Approve or Reject a pull request from this page, the same as approving a governed deployment. Rejecting needs a reason of at least 10 characters. This never creates a GitHub review; it records the decision for the Prodgator approvers rule and updates the check within a few seconds. A person can withdraw their own decision.
• Editors and admins can open View input, which shows the JSON document that evaluation read, or says it is no longer kept once 90 days have passed.
• Admins can click Sync to re-read every open pull request from every connected provider: repositories with the GitHub App installed, projects of connected GitLab groups, repositories of connected Bitbucket workspaces and repositories of connected Azure DevOps organizations. The message after it names the providers it started and any it skipped, such as Bitbucket: not connected, or a connection that needs reconnecting under Admin Console > Integrations. For GitHub it is the same backfill that runs automatically when you bind a policy to pull requests for the first time.
• Admins can open Pull request settings to skip draft pull requests organization-wide and to choose when Prodgator posts its sticky pull request comment: only when failing or waiting, always, or never.

Everyone with reader access or higher sees the full page, including every policy result, evaluation history and who approved or rejected. Only editors and admins see the evaluation's raw input document and the Re-evaluate, Approve and Reject actions; only admins see Sync and Pull request settings.

Staying currentCopy Anchor Link

The page updates itself as evaluations finish and pull requests change: opening, closing, a new commit, a new review, a Prodgator approval. No manual refresh is needed while the page is open, though the refresh button in the top bar reloads it on demand. Behind a firewall or proxy that blocks the realtime connection, the page still catches up every 30 seconds on its own.

RelatedCopy Anchor Link