Geek Answers Handbook

How to specify different .dockerignore files for different assemblies in one project?

I used the tests list in .dockerignore so that it is not included in the image I used to start the web service.

Now I'm trying to use Docker to run my unit tests, in which case I want to include the tests directory.

I checked docker build -h and did not find any option.

How can i do this?

+28
docker
source share
4 answers

Docker 19.03 set a solution for this.

The Docker client first tries to load <dockerfile-name>.dockerignore , and then returns to .dockerignore if it cannot be found. Therefore docker build -f Dockerfile.foo . first tries to download Dockerfile.foo.dockerignore .

Setting the environment variable DOCKER_BUILDKIT=1 is currently required to use this function.

See also:

+6
source share

There is currently no way to do this. There is a long discussion about adding the --ignore flag to the Docker to ensure that the ignore file is used - see here .

The options you have at the moment are mostly ugly:

  • Divide the project into subdirectories, each of which has its own Dockerfile and .dockerignore , which may not work in your case.
  • Create a script that copies the appropriate files to a temporary directory and starts the Docker build there.
+15
source share

Adding cleaned tests as a mount volume in a container can be here. After you build the image, run it for testing, mount the source code containing the tests on top of the cleaned code.

 services: tests: image: my-clean-image volumes: - '../app:/opt/app' # Add removed tests
+2
source share

Another option is the following build process, including tests. How do i do this:

If the tests are unit tests, I create a new Docker image, which is obtained from the main image of the project; I just insert the FROM at the top and then the ADD tests, as well as any necessary tools (in my case, mocha , chai , etc.). This new “test” image now contains both tests and the original source for testing. It can then simply be started as is, or it can be started in browse mode with volumes mapped to your sources and test directories on the host.

If the tests are integration tests - for example, the main image may be a GraphQL server, then the image I created is self-sufficient, i.e. not derived from the main image (it still contains tests and tools, of course). My tests use environment variables to tell them where to find the endpoint that needs testing, and it's easy enough to get Docker Compose to call both the container using the main image and another container using the integration test image, and set the environment variables so the test suite knows what to test.

0
source share

More articles:


All Articles