Example threads. These questions and answers were written by the SDODS team to document real problems and how to fix them. The people named are illustrative, not real users. Questions asked on this site are marked new.
We are about to turn @visual on for real — currently one scenario, about to be fifteen, on two browsers, and eventually two platforms once CI has its own baselines.
Before I commit the first batch: does anyone regret putting the PNGs straight into git? Our repo is already not small and I would rather set up LFS now than migrate later.
Accepted answer
Commit them plainly. Do the arithmetic before you reach for LFS.
A 1280x720 PNG of a mostly flat application UI is tens of kilobytes — flat colour compresses well, and screenshots of forms and tables are mostly flat colour. Fifteen scenarios on two browsers and two platforms is sixty files. That is a few megabytes, once, and thereafter only the ones that genuinely change.
Baselines also want to be reviewable in a pull request and revertable with the commit that broke them. Both of those are worse behind LFS, and neither is worth trading away for single-digit megabytes.
The multiplier to watch is browsers times platforms, not scenarios. Going from fifteen scenarios to thirty adds fifteen files per target; adding webkit and a Linux runner doubles everything you already have, twice.
So the question that actually controls the size of this directory is which browsers earn a pixel baseline. For most teams that is one, and the other browsers get functional coverage instead.
If you do end up on LFS eventually, the failure mode to know about: every job that runs @visual then needs the LFS fetch too, and a job that skips it checks out pointer files — small text files sitting exactly where the PNG should be.
The comparison does not say "this is a pointer file". You get a decode error or a wildly wrong diff, on CI only, on the one job somebody added last week. Perfectly debuggable and a genuinely miserable hour.
One mechanical note in case it is behind the question: the lint walker descends features/ and skips __screenshots__, so a PNG in there is never mistaken for something it should parse.
Which is to say you do not need to move baselines out of features/ to keep the directory tidy for tooling. Leave them where the runner writes them.
Wrap commands and output in triple backticks and they will render as a code block.
Checking whether you’re signed in…
Have a different question? Ask it.