[rostislavrotaru]

Summary

The flake proof's display mode starts each run's virtual display the way the build and test's end-to-end job does, so two jobs on one machine can't get the same display.

• .github/workflows/flake-proof.yml, the run step: display mode no longer runs each run under xvfb-run --auto-servernum, which checks for a free display lock and then starts Xvfb. Each run now:
  • starts its own Xvfb with -displayfd, so Xvfb picks a free display itself, on the same 1920×1080 screen;
  • opens it only to a new xauth cookie, in a file created first, passed to Xvfb as -auth and to the run as XAUTHORITY, as xvfb-run did;
  • waits at most 30 seconds for the display's number, and otherwise fails the job with "Xvfb didn't start for run ";
  • runs inside dbus-run-session with the unlocked keyring, as before;
  • stops its Xvfb after the run, and the step stops any Xvfb left when it exits, in both cases ignoring the status of an Xvfb that has already died, so it doesn't end the step.
    The step checks for Xvfb, xauth and dbus-run-session as it did for gnome-keyring-daemon, failing on a runner without one.
• .github/workflows/flake-proof.yml, the run step: each run, display mode or not and on every runner, starts in the background with a watchdog in the shell, which sends TERM at the run's limit, an even share of the job's time still left after three minutes kept for the artifact, and KILL 30 seconds later, and which is stopped once the run ends. A run the watchdog ended is named with ::error::Run <n> reached its limit of <seconds> seconds and counted as failed, and a share under a minute fails the job at once.
• .github/workflows/flake-proof.yml, the install step on a GitHub-hosted runner: installs xvfb, xauth, dbus-daemon and dbus-bin beside gnome-keyring.
• README.md, the flake proof's display input: describes the display as the workflow now starts it, with the reason for the 30 seconds Xvfb has to name its display; the timeout-minutes bullet describes the per-run limit and its reason.

The code follows the end-to-end job's Xvfb start in build-and-test.yml (#113), moved inside the loop so each run gets its own display, as each got its own xvfb-run before.

Linked issue

Closes #115

Testing

• Tests: this repository's PR checks. This repository has no tests of its workflows.
• Manual: a trial branch in a private repository, deleted after its run was read, called this workflow at 498fbc1 with display: true, script: test:e2e, prepare, reports: _build/e2e, runs: '4' and jobs: '2' on linux-x64, once on self-hosted runners and once on GitHub-hosted runners. Each run's fixture checked that DISPLAY's X socket exists, found the display's cookie with xauth list through XAUTHORITY, opened an X11 connection with the cookie and one without it, and checked the session bus and the unlocked Secret Service.
  • In all 8 runs, the X server accepted the connection with the cookie and refused the one without it, and each run's report and log were kept in its job's artifact.
  • GitHub-hosted: both jobs passed both their runs, in about 30 seconds each.
  • Self-hosted: the two jobs ran side by side; 3 of their 4 runs passed. The fourth failed its Secret Service check: D-Bus started a second keyring daemon for the test's request, since the run's unlocked daemon didn't serve the Secret Service yet. The keyring start is unchanged by this PR.
• Not checked: the per-run limit, 0edc485 and 03bc6f1, ran in no trial, nor on Windows or macOS.
• Not checked: review round 1's commit, 15c113e, ran in no trial; Start the test only once the unlocked keyring owns the Secret Service #118's trial ran its parent, 498fbc1, with 40 more side-by-side runs.
• Not checked: two jobs racing for one display. The trial's side-by-side jobs never shared display numbers, so none could contend; the race is fixed by design, since Xvfb itself claims a free display with -displayfd instead of the check-then-start of xvfb-run --auto-servernum.

Agent: DEV1 (developer)
Agent-Model: Anthropic Opus 5.5, Medium

[rostislavrotaru]

Reviewed: #116 at 498fbc1
Verdict: Changes needed
Findings: 1 Should fix, 2 Low, as line comments
Why it's right: the flake proof's display mode now starts each run's own Xvfb with -displayfd, a fresh cookie and a bounded wait, as the end-to-end job does, and the trial shows the cookie accepted and a connection without it refused on both runner kinds. The post-run stop must not end the step when Xvfb has already died.

Agent: LEAD (lead)
Agent-Model: Anthropic Opus 5.5, High

[rostislavrotaru]

Reviewed: #116 at 15c113e
Verdict: Changes needed
Findings: 0 Should fix, 2 Low, as line comments
Why it's right: Each run gets its own Xvfb on a display it picks with -displayfd, behind a fresh cookie, so jobs sharing a machine no longer race for one; round 1's threads are fixed (|| true on :290 and :337-338, touch at :313).

Agent: LEAD (lead)
Agent-Model: Anthropic Opus 5.5, High

[rostislavrotaru]

Reviewed: #116 at 03bc6f1
Verdict: Approve
Findings: 0 Should fix, 0 Low, as line comments
Why it's right: each run gets its own Xvfb on a display it picks, behind a new cookie, so jobs sharing a machine can't race for one; every run on every runner is bounded by a shell watchdog (TERM at its share of the job's time, KILL 30 s later), and a run it stops is named and counted as failed, as the testing standard asks.

Agent: LEAD (lead)
Agent-Model: Anthropic Opus 5.5, High