Solvedjest image snapshot Question: how are people storing their snapshot images?

I've been using jest-image-snapshot for a while, and I started out storing my snapshots as checked in assets in git, just like I do with my JS jest snapshots. This works great.

However, now that I've got a few hundred snapshot images and they all get updated semi-frequently as UI changes in the app occur, my Git repo is starting to get pretty huge. The historic screenshot files that are in the git repo going back to my first commits aren't really very useful, but they're taking up a bunch of space.

I'm guessing other people must be dealing with this issue too, how are you solving it? Do use some script to store the snapshots externally from your git repo and then .gitignore them? Do you use git-filter-branch to rip out the old snapshots on a periodic schedule? Do you use some other smart way to manage these large binary files?

@itaylor have you considered using LFS to manage your image snapshots?

I've done a POC with Git LFS and it works well. Unfortunately, the company I work at uses Gitlab, and we're not on the newest version and there are incompatibilities with the latest Git LFS versions. I was able to work around this issue by using an older version of Git LFS client 2.4.2 instead of the latest 2.5.1. After jumping that hurdle, using Git LFS was pretty much seamless. My screenshots are no longer being stored inside of the repository, but they're still tracked there, and when I git checkout a branch it goes and fetches them then. When I get a chance I'll make a PR to the docs of this project recommending using Git LFS for those concerned with large repositories.

I've not heard back from many of you, so I've been thinking about this some more, as it seems like it might be a problem that hasn't been solved yet. 😄

Here's an idea that would address this problem.
Right now we do a pixelmatch for each image, comparing the stored snapshot image which lives in the file system (presumably checked in to source control) with the new image.

What if, instead of storing the whole image in the snapshot, we instead stored a SHA hash of the image as the snapshot, and uploaded the actual snapshot image to some file store (like S3 or something like it) with the hash as the filename of the image. Then when comparing images, we would look at the new image, take its hash, if the hash matches, then the image is the same, and the assertion passes. If the hashes don't match, we go and download the old image (we know it's file name because we know its hash) and run pixelmatch to generate the difference image. The functionality would be pretty much the same, but the snapshots we'd store in our source control systems would just be the hashes, taking up very little space, and the snapshot files themselves could then be managed and deleted however needed, outside of source control.

Any thoughts about this idea?

@10xLaCroixDrinker Thanks for the tip on LFS!

I've been using Git daily for about a decade, but somehow I hadn't heard of LFS, and yes, after a cursory look at the docs, it seems like it should completely solve my issues with being able to effectively store large amounts of large screenshot files in the Git repo!

It's seems to be basically the same idea I suggested, using the filename as the hash, uploading the file to a file store and then just storing the hash in the repo, except it's built in to Git and has been fully supported by major Git repositories like Github/Gitlab/Bitbucket for a few years now 😃. I'll give it a try sometime over the next week or so and report back if it works for me. If it does work well, then maybe we could just add a couple of lines to the Readme.md file suggesting using it and we can close this ticket.