Should HAR files go into git? Ours are nearly a megabyte each
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.
Three recordings and the repository is a couple of megabytes heavier:
Two worries. Size, obviously, since every re-record rewrites the whole blob and the history grows. And the login one — that recording was made while signed in, so I would rather like to know what is in it before I push. Gitignore them and rebuild in CI, or commit?
Commit them. The entire point of a recording is that CI does not need the application to be reachable; a HAR that CI has to rebuild is a HAR that buys you nothing. Treat them the way you treat visual baselines: checked in, reviewed in the diff, refreshed on purpose.
On the credentials, your instinct is right and it is handled, but you should know how. The browser HAR is written by Playwright itself, verbatim, including the Cookie, Set-Cookie and Authorization headers of the application under test. So sdods har record scrubs the directory after the run and tells you what it touched:
text
scrubbed 214 credential value(s) from 3 HAR file(s)
Values are replaced with *** rather than the headers being deleted, so replay still matches on their presence. The API layer never has the problem: it redacts those headers as it builds the entry.
Read the diff of the first recording you commit. That is the one where you find out that your application puts something interesting in a header nobody thought to name.
On the size: most of that 926 KB is embedded response bodies, and for a UI recording that means the bundle, the CSS and every image the page pulled. There is not much to trim after the fact — the place to cut is at record time, by limiting what gets captured at all:
bash
bun run sdods har record -p demo-shop -e staging --interactive --name products --url /inventory.html --har-glob "**/api/**"
A HAR captured with a narrow glob is a few KB instead of a megabyte. The catch is that anything you excluded now goes to the real network on replay, so a strict offline run will abort on it. Narrow globs are for API traffic, not for pages you want to render offline.
Worth adding for anyone finding this later: API-layer recordings are nothing like this size. Ours run 2 KB to 100 KB because there is no bundle, no fonts and no images in them, only the JSON. If your project is mostly @api scenarios the whole storage question evaporates.