ci: retry a hung visual shard on the PR run too

[mfal]

The retry from #3090 landed on the label and scheduled workflows only. test.yml's visual job called vitest itself, so the shard invocation and its retry lived in two places. This points the job at run-visual-shard, the action the other two paths already use.

What changes

• browser input on the action. Empty stays both browsers — what the scheduled and label runs need — and test.yml passes webkit, keeping the existing trade of the dark theme for half the wall clock. The input also keys the Playwright cache, so a WebKit-only save can no longer leave a full run without Firefox.
• install: "false" on prepare-browser-tests. The visual job uses it as the nx affected gate only; the action installs the browser it renders in. Every other caller is untouched.
• Timeout 20 → 35 minutes. Three attempts of a shard have to fit inside the job. A shard is 3-6 minutes green and ~8 when every screenshot times out, plus ~3 for setup and the build.
• CONTRIBUTE.md documents the retry, and both it and the comments name what the retry does not cover — see below.

What the retry does not fix

The first push of this PR asserted that the retry would have saved run 33626981366. Its own CI falsified that, so the claim is out of the comments.

Shard 1 here and shard 5 of the label run failed all three attempts identically — 85 of 86 tests, and 118 of 120, reporting Could not capture a stable screenshot within 5000ms from the first test on, in both browsers, while every other shard passed in four minutes. The attempts share the runner, so a machine that produces this fails all of them. The retry covers a hung browser process, which is the Firefox failure mode; it cannot cover this one.

Nor is it this PR's regression: the same whole-shard red hits roughly 4 of every 10 runs on main, a different shard each time (33631694282, 33626556173, 33608121174, 33607745081, 33599165776), and run 33626981366 was one of them. It wants a fix at the root — worth its own issue.

That leaves a question for review: on the WebKit-only PR path attempts: "3" now triples the time to a red signal on a genuine diff (26 minutes instead of 8), and WebKit has not been seen to hang. Keeping it aligns the three paths; setting it to 1 here keeps the fast red. I lean towards keeping it aligned, but it is a real trade.

Verification

Both paths run on this PR: CONTRIBUTE.md makes remote-react-components affected, so test.yml's visual job exercises the new WebKit path, and the run-visual-tests label runs the changed action in its both-browsers default. The retry loop itself is confirmed working — three attempts, a warning between them, the shard's own exit code.

One-off cost: the action's cache key changes from playwright-<os>-<hash> to playwright-all-<os>-<hash>, so the label and scheduled runs install both browsers cold once.

related #3090

🤖 Generated with Claude Code

[github-actions]

Coverage Report for ./packages/components/

Status	Category	Percentage	Covered / Total
🔵	Lines	78.69%	746 / 948
🔵	Statements	78.57%	763 / 971
🔵	Functions	80.09%	165 / 206
🔵	Branches	70.33%	377 / 536

File Coverage

No changed files found.

Generated in workflow #6593 for commit 5ca6225 by the Vitest Coverage Report Action

[github-actions]

🚀 Preview Deployment

Preview environments are ready:

Type	URL
docs	pr-3104.docs.review.flow-components.de
storybook	pr-3104.storybook.review.flow-components.de

Images:

• docs: ghcr.io/mittwald/flow/docs:pr-3104
• storybook: ghcr.io/mittwald/flow/storybook:pr-3104

[github-actions]

❌ Visual Regression Tests Failed

At least one shard did not pass. If snapshots differ from the committed baselines, download the visual-diffs-* artifacts from this run to inspect the actual/diff images (a shard that failed before comparison, e.g. during install or browser setup, leaves none).

If the differences are intentional, update the baselines by adding the update-screenshots label to the PR.

Run details

[mfal]

Closing this. The retry it wires into test.yml is being reverted on the label path in #3107, for the reason this PR's own CI produced: three attempts of a shard fail identically, because they share the runner.

The failure is filed as #3106. The parts of this PR that stand on their own — pointing test.yml's visual job at run-visual-shard instead of a duplicated vitest invocation, and the browser input that lets the action render in one browser — are worth having, but they are deduplication rather than a fix, and they read better once #3106 has settled what the shard invocation should look like. The branch stays on ci/retry-visual-shards-on-pr.

🤖 Generated with Claude Code