What Midstream puts on a pull request

When CI captures scenes on a commit that is the head of an open pull request, Midstream writes two things onto that pull request. This article says what they are, where to click, and how we decide which scenes the pull request touches.

The check

Midstream posts one check on the commit, named Midstream Scenes. Its summary counts the scenes the pull request touches:

Found 4 scene(s) for PR #128

The check is there to tell you something changed, not to grade the change. It always reports a neutral result, so it never fails your pull request and never blocks a merge.

The deployment link

Midstream also adds a preview deployment to the pull request. Its link goes to the Midstream view of that pull request. GitHub shows it alongside the checks and in the pull request's timeline, so a reviewer who has never opened Midstream has one obvious thing to click.

The pull-request view

The link lands you on the pull request inside Midstream. You get the number and title, the branch, the head commit, and a card for every scene the pull request touches. Click a card to open that scene, where you can launch an instance and click around in the change. See Opening an instance.

If nothing is touched, the view says so plainly — that is a normal result for a pull request that changes code no scene passes through.

You can reach the same view without leaving Midstream: Upcoming changes in a project lists the open pull requests, and each one links to its view.

Every capture on the commit also picks up the pull request number and its author, so a scene's history shows #128 @author against that capture instead of a bare commit hash.

What counts as touched

We compare the captures on the pull request's head commit against the captures on the commit it branched from. A scene counts as touched if any of these is true:

1. It was added or removed. The scene exists on one commit and not the other.
2. Its test file appears in the diff. The file the scene call lives in was changed by the pull request.
3. Its accessibility snapshot changed. Every capture stores a structural, text-only picture of the page at that moment; this one's differs from the base's.
4. Its screenshot changed. The captured image is not the same image, or exists on one side and not the other.

The rules are checked in that order and the first match wins, so a scene is listed once no matter how many of them apply.

Two things follow from this. A scene in the list means "worth a look", not "broken" — a deliberate copy change trips rule 3 exactly as a bug would. And the comparison needs captures on both commits: if CI has never captured scenes on the commit your branch started from, every scene on your branch looks new, and they all show up as touched.

Timing

Updates are grouped per commit. A test suite that captures a hundred scenes produces one update, not a hundred: we wait for the captures to stop arriving — about a minute — and then write the check and the deployment once.

Push again and the new commit gets its own check, compared against the same base.

If nothing shows up

Midstream needs three things to write to a pull request: the repository is connected to a project, captures arrived from CI for the pull request's head commit, and that commit is the head of an open pull request. The most common cause of a silent pull request is the second one — CI ran but no captures were registered, usually because the test failed before it reached the scene call.