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 from the Filters menu left of the search box. Each category shows how many pull requests match each value, counted against every other filter you have set. Active filters show as chips under the search box, with Clear all. 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 people who hold those permissions (see below).
• 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.
• Checks: the checks the provider reported for the head commit, grouped by result (failed, pending, unknown, neutral, passed). Each row shows its result, name, app, source (check run, commit status, pipeline or external), how long it took or when it ran, and a link to the provider when it gives an https address. Prodgator's own checks carry a Prodgator tag. The header shows the short head commit and the counts, and a line says when more checks exist than are shown. Earlier head commits are listed below, collapsed, each with its commit and counts. Until the provider reports a check for the head commit, the section says none are reported yet; Prodgator records them as the provider reports them. The record is also kept on the change as a checks_reported event (see Timeline).
• 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.

Who can do whatCopy Anchor Link

• Developers, Release managers, Security, Compliance and Org 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.
• Release managers and Org 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.
• Developers, Release managers, Security, Compliance and Org 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.
• Release managers and Org admins (Override release policies) can override a blocked pull request's check for its current head commit, with a reason (Business and Enterprise).
• Org 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 Organization > Integrations. For GitHub it is the same backfill that runs automatically when you bind a policy to pull requests for the first time.
• Org 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.

Every member sees the full page, including every policy result, evaluation history and who approved or rejected. Only people who hold the matching permission see the evaluation's raw input document and the Re-evaluate, Approve and Reject actions; only Org 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