Answers: <p>Yes, you are doing the correct approach. Or rather, "a" correct approach, in your specific circumstance.</p>
  
  <p>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 <em>container</em>) you are checking out the test script, and running it.</p>
  
  <p>The more usual alternative would be to leave the actual <code>git checkout</code> 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 <code>git checkout</code> 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 <code>git checkout</code> 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.</p>
  
  <p>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.</p>
  
  <blockquote>
    <p>I do not need any product code, my scripts is all that is required</p>
  </blockquote>
  
  <p>So you would never actually <em>deploy</em> those images anyways - hence it is perfectly fine to not build them each time. You still should be <em>automatically</em> 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 <code>ADD</code> / <code>COPY</code>) changes. Not for technical reasons, but to avoid a manual step.</p>
  
Answers: CC BY-SA 3.0
Answers: 2017-12-24T14:46:16.980Z
Answers: 2017-12-25T11:34:55.823Z
Answers: 2017-12-25T11:34:55.823Z
Answers: AnoE
Answers: <p>I do not understand why a docker container should perform the checkout as this could be done using Jenkins.</p>
  
  <p>One of the advantages of docker is that it is immutable, but the way you use it right now is mutable.</p>
  
Answers: CC BY-SA 3.0
Answers: 2017-12-24T16:35:51.257Z
Answers: 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.
Answers: Tensibai
Answers: CC BY-SA 3.0
Answers: 2017-12-24T17:20:15.807Z
Answers: Agreed. Another advantage is that a docker image will use less resources than a VM as the OS is omitted.
Answers: 030
Answers: CC BY-SA 3.0
Answers: 2017-12-24T18:11:59.503Z
Answers: It's not really omitted, it's the host kernel being used...
Answers: Tensibai
Answers: CC BY-SA 3.0
Answers: 2017-12-22T06:54:23.640Z
Answers: 2017-12-22T06:54:23.640Z
Answers: 030
Body: <p>For my test environment, I am trying to setup the following setup. </p>
  
  <p>Create scripts in Frisby</p>
  
  <p>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. </p>
  
  <p>My question about the dockerfile. When I create the image for spinning the container. What is the best way to create the image file.</p>
  
  <p>My assumption is as following</p>
  
  <ul>
  <li>use evagra/jenkis slave image and add on it,</li>
  <li>installation for Frisby</li>
  <li>do a checkout of my scripts</li>
  <li>run command for my scripts.</li>
  </ul>
  
  <p>Is this the right approach. </p>
  
Comments: CC BY-SA 4.0
Comments: 2019-12-23T07:56:30.053Z
Comments: Could you indicate whether you solved the issue?
Comments: 030
Tags: <docker><jenkins><dockerfile>
Title: docker container for running automation scripts using jenkins
UserDisplayName: user1555608
ThreadText: # docker container for running automation scripts using jenkins
  
  (Asked by: username_0 on 2017-12-14)
  
  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.
  
  **Tags:** docker, jenkins, dockerfile
  
  > **Comments:**
  > **username_1**: Could you indicate whether you solved the issue?  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_2 on 2017-12-24. Score: 4
  
  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.
  
  
  ---
  
  ### Answer by username_1 on 2017-12-22. Score: 1
  
  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.
  
  > **Comments:**
  > **username_3**: 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.  
  > **username_1**: Agreed. Another advantage is that a docker image will use less resources than a VM as the OS is omitted.  
  > **username_3**: It's not really omitted, it's the host kernel being used...  
  
  ---
  
  