For my test environment, I am trying to setup the following setup.

Create scripts in Frisby

Have a jenkins job, which creates a slave which is a docker container. The docker container will checkout my latest scripts from my git repository, and run the tests in the container. Since its api tests, I do not need any product code, my scripts is all that is required which will be connecting to API to test.

My question about the dockerfile. When I create the image for spinning the container. What is the best way to create the image file.

My assumption is as following

  • use evagra/jenkis slave image and add on it,
  • installation for Frisby
  • do a checkout of my scripts
  • run command for my scripts.

Is this the right approach.

  • Could you indicate whether you solved the issue?
    – 030
    Commented Dec 23, 2019 at 7:56

2 Answers 2


Yes, you are doing the correct approach. Or rather, "a" correct approach, in your specific circumstance.

You are proposing to build the image beforehand, not as part of each individual Jenkins job. Then your Jenkins job will consist of running the image; and in that ephemeral state (i.e., inside the container) you are checking out the test script, and running it.

The more usual alternative would be to leave the actual git checkout to Jenkins, and pull the script into your container with a bind volume. Jenkins has to be able to access your git repository anyways, so you get this checkout for free. There are two sides to the coin here: if you do the git checkout from inside the container, then you can run your test outside of Jenkins with no change whatsoever - say, during development, on your own machine. In any case, if you do the git checkout from inside, and if you need credentials to access the git repository, be sure to handle those securely. Don't put cleartext passwords in the image, or ssh keys with an empty passphrases.

The benefit you are getting from this is that your test environment (libraries, 3rd party test drivers and so forth) is well defined, so you can run it on any Jenkins node you have available. By not creating new images whenever your code changes, you avoid creating and distributing new images for every job.

I do not need any product code, my scripts is all that is required

So you would never actually deploy those images anyways - hence it is perfectly fine to not build them each time. You still should be automatically building your images - no matter if you do it as part of the actual job, or as a separate job which only does it when the Dockerfile (and whichever files it pulls in with ADD / COPY) changes. Not for technical reasons, but to avoid a manual step.


I do not understand why a docker container should perform the checkout as this could be done using Jenkins.

One of the advantages of docker is that it is immutable, but the way you use it right now is mutable.

  • 1
    Using docker containers as immutable artifacts is an usage, like cloning a vm from a template each time instead of modifying it, that's not really a feature or advantage of docker, the advantage is it's quicker to spin up a container than a vm.
    – Tensibai
    Commented Dec 24, 2017 at 16:35
  • Agreed. Another advantage is that a docker image will use less resources than a VM as the OS is omitted.
    – 030
    Commented Dec 24, 2017 at 17:20
  • It's not really omitted, it's the host kernel being used...
    – Tensibai
    Commented Dec 24, 2017 at 18:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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