Our dockerfile creates the application environment (e.g. env variables, install libraries with apt-get etc.). It also pulls and copies the python application code from its git repo.

However, we are debating whether the application tests (some unit, some integration) should be put within a docker RUN command (e.g. RUN /bin/bash -c "source activate cool_env; pytest") or after the build using the CI stack (e.g. Jenkins, Openshift) to execute the tests on the built container.

What are the pros and cons of each?

  • there is also a new feature, multi-stage builds which allows you to have both build and test in the same Dockerfile. – Peter Muryshkin Sep 7 '17 at 5:05

I support J.Doe's suggestion for separate Docker files for each of the build and test stage. Such approach also allows you to:

  • re-run the test stage for whatever reason (known intermittent failures, for example) without re-doing the build stage
  • run multiple different test stages in parallel using the same build - for example instead of running a single long test stage made up of serialized tests, for a potentially significant overall pipeline speeding up.

If you run everything in the same container...

PRO: you have solved the CasC challenge for configuring the testing environment inline as well

CON: you miss the blackbox tesing part, imagine your container wouldn't accepts connections from outside. Ouch!

Possible solution: I'd go therefore for a multi-stage Docker-based declarative pipeline: one Docker environment for each stage where artefacts cascade along it.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.