Closed wszaranski closed 7 months ago
Difference can be observed between run when cache wasn't available (2m44s) and when it was available (49s).
I think that it would be funny to use competing solution (testcontainers) to run miniredis integration tests.
Miniredis is smaller, way faster and doesn't require external dependency (docker) which is great :heart: but maybe we can mention testcontainers in README for people that require features not implemented in miniredis?
Fun, thanks!
Testcontainers look fun, but there are similar things which also work well (for example https://devenv.sh/ ), so I think it's a bit out of scope to pick something. But then again a short "Other options" (or whatever) section in the readme is fine with me :)
${MAKE} -C integration redis_src/redis-server
that is part ofci
target takes around 2 minutes to execute. With addition of cache preventing rebuild ofredis-server
tests run time drops from ~2m50s to ~50s.Currently github actions are free for public repositories but I think that shorter execution time will improve developer experience :)
Due to matrix build for go versions, when redis is upgraded, build will be run multiple times in parallel. Unnecessary parallel builds can be avoided but since we don't upgrade redis too often I feel it would be unnecessary complication.
Perhaps even better solution might be usage of testcontainers. Integration tests would basically download and run official redis docker image and spin it up for tests. There would be no need for cache or building binary but docker dependency would be introduced. I have decided to introduce cache because docker dependency has pros and cons that need to be discussed while cache is clear and easy win ;)