To try to get integration tests usable in CI, I've been exploring docker environments with Pants. The concept is really useful! One bit I'm missing is that we need to, before our integration tests start up, start various services. However, Pants seems to override our Docker entrypoint, so there's no way for us to run the setup we need to. Am I missing a solution to this (besides to just handle it from our unit tests itself, which is possible but annoying)? If not, I'm happy to write up as a feature request, which is basically to allow us to specify some Docker executable to run on setup before whatever Pants wants to run.

Can you be more specific about the symptoms of “seems to override our docker entry point “? (At my work; we run a few services via

docker compose up

before running

pants test ::

and the tests can happily connect to databases etc.)

Thanks for the reply! My entrypoint is a shell script that sets up a few things. It never gets run, because I believe Pants just supplies its own entrypoint via flags to docker when it runs things (or at least tests) in a docker environment. I'm curious how you run things with

docker compose up

, I guess this is outside of pants because IIUC, pants doesn't integrate with

docker compose

. Do you have a wrapper script around testing that does this?

Yes outside of pants. But we’re just running external services that the code running natively (no docker) connect to, there’s nothing we build in our repository running inside docker, which sounds like it may not be so applicable to your case. If you can share, what you currently do that is working? (Ie before using pants’ docker environments)

Well, we can run our integration tests on our local machines, but getting them running on Github workflows is a major pain (mostly because of the fact that it's not possible to test locally). So I figured it's better to get something running locally in a docker image and then get that running on Github, and if we want to run integration tests, then using docker environments seems like the only reasonable solution to me. Another problem, though is that with docker environments, every time you run a test you get another docker container. So it's a solution, but it brings its own problems which I haven't figured out how to solve yet.

Not sure if related, but I use pytest-docker to start a compose file and then run tests against the services started with the compose file. The service docker images are deps of the test, so they get rebuilt before running if necessary. The test code itself runs outside docker.