This pr takes a leaf (ok, the whole book) from this riffraff pr: https://github.com/guardian/riff-raff/pull/690, and removes the docker-testkit-scalatest dependency which is no longer maintained and currently breaks CI (it is not compatible with the latest versions of Docker, last working version 24), in favour of spinning up/down dynamodb-local Docker containers as part of the sbt test set-up/clean-up.
How to test
The tests should pass in CI. You should also be able to run tests on your local machine.
How can we measure success?
We are able to merge path manager prs once more!
Have we considered potential risks?
The one downside to this approach is if you are using the local db for development and have data in your local db, it will be lost the next time tests are run locally and the container is spun up/destroyed. For this project, that seemed reasonable, but if we were to apply this approach to other projects, we may decide to persist the local db.
What does this change?
This pr takes a leaf (ok, the whole book) from this riffraff pr: https://github.com/guardian/riff-raff/pull/690, and removes the
docker-testkit-scalatestdependency which is no longer maintained and currently breaks CI (it is not compatible with the latest versions of Docker, last working version 24), in favour of spinning up/down dynamodb-local Docker containers as part of the sbt test set-up/clean-up.How to test
The tests should pass in CI. You should also be able to run tests on your local machine.
How can we measure success?
We are able to merge path manager prs once more!
Have we considered potential risks?
The one downside to this approach is if you are using the local db for development and have data in your local db, it will be lost the next time tests are run locally and the container is spun up/destroyed. For this project, that seemed reasonable, but if we were to apply this approach to other projects, we may decide to persist the local db.