Pull requests

Pull requests lists every pull request that ran in a period and reads it against the branch it merges into: did it break a test that passes there? Open it from the sidebar, under Runs.

One row is one pull request. Pull requests that broke a test come first; among them, and among the rest, the newest run comes first. Every row starts closed; the arrow at its end opens it and shows the pull request’s runs as a timeline. Any number of rows can be open at once.

Which runs belong to a pull request

A run belongs to a pull request when GitHub names the run’s commit in one. Squally asks GitHub when a CI run finishes - for a project linked to a repository through the GitHub App - and it is the same pull request the run’s PR #n chip shows on the runs list. A local run is never asked about, so it is not on this page. Without a linked repository, no run has a pull request and the page stays empty.

A page view reads at most 300 runs of pull requests, the newest. When the period had more, the page says so under the list: “Showing the pull requests of the newest 300 runs. Choose a shorter period to see all of them.”

The filter sentence

Showing open pull requests from the last 30 days compared with their target branch

• State - open (the default) shows open and draft pull requests, and every one whose state GitHub has not told Squally; draft, merged and closed show only pull requests in that state; all shows every one. See State icons.
• Period - the last 7, 14, 30 (the default) or 90 days.
• Compared with - their target branch (each pull request against the branch it merges into), or one branch for every pull request: any branch with a run in the last 90 days. See Compared with.
• Search - a title, a number such as #412, or a branch.

The ⓘ next to the sentence sums up the rules below.

A sentence under the title reports the period, for example “2 of 9 pull requests break tests that pass on main; one fixes a test that fails there.” When the pull requests are compared with different branches, it says “on their base branch”.

What a row shows

• the pull request’s state icon, and PR #412;
• its title, and under it the branch, the latest run’s commit, its author and “latest run #128” with that run’s status in front of the number;
• the verdict against the branch it is compared with. The sentence over the list names that branch; a row repeats it only when it says more - “compared with main (assumed)” when Squally had to guess the branch, or “compared with develop” when the pull requests on the page are compared with different branches;
• its last runs as squares, oldest first, by the run’s status - failed, passed (tests that passed only after a retry included) or not finished - and how many runs it had in the period;
• the latest run’s duration and when it started.

Verdicts

Every failed test of a run is read against the latest finished run - passed or failed, CI or local, from the last 90 days - on the branch the pull request is compared with:

Verdict	Meaning
New in this pull request	Fails here, and passes on that branch (or was flaky or skipped there) - this pull request broke it
New test, failing	Fails here, and that branch does not have the test - a test the pull request adds that does not pass yet
Already fails on main	Fails on that branch too - not caused by this pull request. The label names the branch
Fixed	Fails on that branch, passes here (or passed after a retry) - and fails here in no project

A test counts once across Playwright projects, as on the Overview: “finds a product” in chromium and in firefox is one test. Each project’s result is read against the same project on that branch - chromium against chromium - and the test then takes the first of its projects’ verdicts in this order: New in this pull request, New test, failing, Already fails on main, Fixed. So a test that still fails in one project is not fixed because another project passes now.

The row’s verdict is its latest finished run against that branch, counted in tests. Its first line is what the pull request does: Breaks 2 tests (in red), else Adds 1 failing test, else Fixes 1 test, else No new failure, else No failure. Under it, in grey, the rest one per line - “1 other test already fails on main”, “fixes 1 test” - or what the first line means: “that fails on main” under Fixes 1 test, “3 tests already fail on main” under No new failure.

Not compared yet instead of a verdict, with the reason under it: the latest run is still running or was cancelled, the pull request has no finished run, there is no finished run on the branch in the last 90 days, or no branch to compare with is known.

The timeline

Open a row to see its runs, newest first - at most the latest 10. Each run shows its number (a link to the run), its commit subject and SHA, what failed in it, and its duration over when it started. What failed leads with the tests and puts the results in brackets - “2 failed tests (4 results) · 1 flaky”, or “All 48 results passed”. Results are counted per project as on the run’s own page - a test in chromium and in firefox is two; flaky and skipped are results.

Click a run’s counts to unfold its tests. They are what changed against the run before it, one test each with the projects it changed in - “New in this pull request finds a product · chromium, firefox”:

• a test that started failing, with its verdict - New in this pull request, New test, failing or Already fails on main;
• Fixed - a test that failed in the run before and passes now (a test that is skipped or gone now, or still fails in another project, is not counted as fixed).

Hover a label for its meaning. A run without a change says so instead: “Same failures as #121.”, “Nothing failed.” or, for the first run, “First run: nothing failed.” A cancelled, running or incomplete run says that. Each test links to its page - at the run’s project when it changed in one, across all projects when it changed in several.

Under the timeline:

• Compare with main opens the comparison of the pull request’s latest run with that branch’s run.
• Open in Runs opens the runs list searched for the pull request, pr 412.
• View on GitHub opens the pull request on GitHub, in a new tab - when Squally knows its repository. A pull request known only from runs that name no repository has no such link.

Compared with

The branch a pull request is read against is the first of these that applies:

1. the branch chosen in the page’s compared with - for this visit only;
2. the project’s Compare pull requests with setting - see Project settings;
3. the branch the pull request merges into, as GitHub reports it;
4. main, else master, when the project has runs on it - shown as “(assumed)”, because Squally guessed.

Choosing their target branch in the sentence overrides the project setting for the visit, too. When none of the four applies, the row reads “no base branch to compare with”.

State icons

The icon at the start of a row is the pull request’s state, drawn the way GitHub draws it:

Icon	State
Pull request icon, green	Open
Dashed pull request icon, grey	Draft
Merge icon, purple	Merged
Closed pull request icon, red	Closed
Pull request icon, plain grey	State unknown

Hover the icon for its state in words; a screen reader reads it, too. The icon says nothing about the runs - how they went is in the squares on the right.

Squally learns the state only through the GitHub App: when a CI run finishes, and from GitHub’s Pull request event whenever a pull request is opened, closed, merged, reopened, edited, marked as draft or ready for review, or gets new commits. The newest of GitHub’s descriptions wins.

A pull request Squally has not heard about this way shows the plain grey icon - its state is never guessed. It counts as open: the default filter keeps it; draft, merged and closed do not.

Under open, merged and closed pull requests are hidden, and a line under the list counts them: “2 merged or closed pull requests are not shown. Show all”.

When there is nothing to show

• A project that has never reported a run shows No pull requests yet - “Runs of pull requests appear here once runs arrive.” - with a link to the Overview.
• A period without a pull request run shows No pull request ran in the last 30 days. When the state filter hides some, it names the state instead: “No open pull request ran in the last 30 days” - or draft, merged, closed.
• A search without a match shows No pull request matches - “Try a title, a number like #412, or a branch.”

Retention

A pull request stays on the page as long as its runs do - runs are kept for your plan’s retention period. What Squally stores about a pull request - its title, branches and state - is deleted once retention has removed its last run, and with the project.