You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Screenshot harness is still not reproducible across a full run #326
A full npm run shots run is still not always reproducible. site-menu.png and stale-site-notice.png sometimes differ between two runs with no code change in between.
Each of those shots is reproducible on its own under --only. That rules out the shot's own prepare and points at state shared across shots in one app instance — the fixture tier launches one Electron per variant and reloads the window between shots, which resets the renderer but not the main process, its network stack, or any cached GitHub response.
Two causes were already fixed in #277: CSS animations are frozen at their first frame, and selectSite waits out the linked-pull-request lookup. Those took the churn from three images per run to an occasional two, and fixed a real docs bug on the way — the same run had produced site-view.png mid-check and trac-ticket-panel.png already resolved.
Ending it properly means the fixture never reaching GitHub: a test-mode flag the main process reads, serving canned responses instead. That is app-level work, not harness work, which is why it is not in #277.
Worth doing because the UI polish pass is a stack of seven PRs over these same images. A PNG that changes on its own turns every rebase into a binary conflict on a file nothing actually changed, and a binary conflict has no resolution but to pick a side and re-capture.
To reproduce: npm run shots, git checkout docs/, npm run shots again, git status.
Activity
Update @wordpress/components from 28 to 41 as the base for the design…
Name the controls the journeys and the screenshots share in one helper (