Answers: <p>I still dont see how starting an agent creates a clean image.  Expanding on your setup would help us provide better answer.</p>
  
  <p>That said, from what I can gather here the following assumption comes to mind :</p>
  
  <ul>
  <li>You have agents pre-populated on a VM image.  Starting this image will in turn start the agent in which you wish to start the build.</li>
  </ul>
  
  <p>So you now have a chicken vs egg problem where you need the agent running to start the job but you need to start the agent as the job starts.</p>
  
  <p>Why not have <em>another</em> agent who's job is to start the image.  This new agent is no longer sensitive to the image cleanliness and can run indefinitely.</p>
  
  <p>My approach here would take this a step further and not have the agent as part of the image altogether, but rather have the agent first start the image, provision it with whatever is needed for the build in some way, and then run the build.</p>
  
  <p>A simple shared folder on the image with the host could do the work.  Tools like Vagrant could also be of use.  But without more information it's really difficult to go further.</p>
  
  <p><a href="https://stackoverflow.com/questions/38616906/jenkins-trigger-on-demand-slaves-in-dockers">This answer</a> on stack overflow could also contain some help in this regard.  Basically spins-up a new docker image on demand.</p>
  
  <p>Another possible way with your current setup, make sure the build always ends with a shutdown of the image. This way the next job will be sure to use a fresh image as it <em>should</em> never survive the build.  You could even test fort his situation and fail the build outright if you detect the image was re-cycled between builds rather than re-launched.</p>
  
Answers: CC BY-SA 4.0
Answers: 2023-03-21T04:40:12.110Z
Answers: "I still dont see how starting an agent creates a clean image." VMs with readonly root keep the FS in memory and on cycling anything not part of the readonly image are lost.
  
  I have a similar use-case. I have a writable overlay image for my agents with a backing file that contains the OS and everything else. Once a build is complete, I want to shutdown the agent so that hooks in libvirt can run and re-provision the writable overlay.
  
  So, to answer the unasked question, there are a few ways that restarting gets a clean environment.
Answers: Ungeheuer
Answers: CC BY-SA 4.0
Answers: 2023-03-23T05:29:48.830Z
Answers: >VMs with readonly root keep the FS in memory and on cycling anything not part of the readonly image are lost.  ... Ha! interesting yes ! 
  thanks for the info
Answers: Newtopian
Answers: CC BY-SA 4.0
Answers: 2018-12-07T17:16:20.527Z
Answers: 2018-12-07T17:23:05.470Z
Answers: 2018-12-07T17:23:05.470Z
Answers: Newtopian
Answers: <p>Slave restarts the agent itself after each build? You can use <a href="https://wiki.jenkins.io/display/JENKINS/Conditional+BuildStep+Plugin" rel="nofollow noreferrer">Conditional BuildStep</a> plugin to restart it on a defined condition.</p>
  
Answers: CC BY-SA 4.0
Answers: 2018-08-25T10:46:55.310Z
Answers: 2018-11-06T12:11:16.393Z
Answers: 2018-11-06T12:11:16.393Z
Answers: hakkican
Body: <p>How do I configure jenkins to restart the agent for <strong>each</strong> build?</p>
  
  <p>I tried to use "<em>launch method: launch agent via execution of command on the master</em>" in combintation with "<em>availability: take this agent online when in demand, and offline when idle</em>" but it has two drawbacks:</p>
  
  <ol>
  <li>(not critical) build starts with a delay of about one minute.</li>
  <li>(critical) the node goes offline only a minute after the end of the build, and if another build starts at that time, <strong>the same</strong> still running agent will be used (even if there are several similarly configured free nodes).</li>
  </ol>
  
  <p>There is even a plugin (<a href="https://wiki.jenkins.io/display/JENKINS/Scripted+Cloud+plugin" rel="nofollow noreferrer">scripted cloud plugin</a>) that, according to the description, should be suitable, but it does not work, probably because its code is outdated.</p>
  
Comments: CC BY-SA 4.0
Comments: 2023-03-21T04:41:14.877Z
Comments: Aleksandr, what was your solution for this? I have a similar use-case in that I need to cycle my agents after a build.
Comments: Ungeheuer
Comments: CC BY-SA 4.0
Comments: 2018-12-07T13:47:37.703Z
Comments: Curious ... why do you need the agent to be restarted for each build ?  At first glance that sounds suspicious to me where you might be trying to solve the wrong problem.  But without context it's hard to evaluate.
Comments: Newtopian
Comments: CC BY-SA 4.0
Comments: 2018-12-07T14:24:54.803Z
Comments: @Newtopian, each build requires a clean image, and each start of agent creates clean image. if the agent does not restart, a dirty image is used. that's the problem.
Comments: aleksandr barakin
Comments: CC BY-SA 4.0
Comments: 2018-12-07T17:07:47.250Z
Comments: hmmm...   I see...  my first reflex here would be to inverse this dependency where the agent would start the image and run the build on it.  I'll move the the rest in an answer.
Comments: Newtopian
Tags: <jenkins>
Title: Restart agent for each build
UserDisplayName: aleksandr barakin
ThreadText: # Restart agent for each build
  
  (Asked by: username_0 on 2018-08-22)
  
  How do I configure jenkins to restart the agent for **each** build?
  
  I tried to use "*launch method: launch agent via execution of command on the master*" in combintation with "*availability: take this agent online when in demand, and offline when idle*" but it has two drawbacks:
  
  1. (not critical) build starts with a delay of about one minute.
  2. (critical) the node goes offline only a minute after the end of the build, and if another build starts at that time, **the same** still running agent will be used (even if there are several similarly configured free nodes).
  
  There is even a plugin ([scripted cloud plugin](https://wiki.jenkins.io/display/JENKINS/Scripted+Cloud+plugin)) that, according to the description, should be suitable, but it does not work, probably because its code is outdated.
  
  **Tags:** jenkins
  
  > **Comments:**
  > **username_2**: Curious ... why do you need the agent to be restarted for each build ?  At first glance that sounds suspicious to me where you might be trying to solve the wrong problem.  But without context it's hard to evaluate.  
  > **username_0**: @username_2, each build requires a clean image, and each start of agent creates clean image. if the agent does not restart, a dirty image is used. that's the problem.  
  > **username_2**: hmmm...   I see...  my first reflex here would be to inverse this dependency where the agent would start the image and run the build on it.  I'll move the the rest in an answer.  
  > **username_1**: username_0, what was your solution for this? I have a similar use-case in that I need to cycle my agents after a build.  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_2 on 2018-12-07. Score: 2
  
  I still dont see how starting an agent creates a clean image. Expanding on your setup would help us provide better answer.
  
  That said, from what I can gather here the following assumption comes to mind :
  
  * You have agents pre-populated on a VM image. Starting this image will in turn start the agent in which you wish to start the build.
  
  So you now have a chicken vs egg problem where you need the agent running to start the job but you need to start the agent as the job starts.
  
  Why not have *another* agent who's job is to start the image. This new agent is no longer sensitive to the image cleanliness and can run indefinitely.
  
  My approach here would take this a step further and not have the agent as part of the image altogether, but rather have the agent first start the image, provision it with whatever is needed for the build in some way, and then run the build.
  
  A simple shared folder on the image with the host could do the work. Tools like Vagrant could also be of use. But without more information it's really difficult to go further.
  
  [This answer](https://stackoverflow.com/questions/38616906/jenkins-trigger-on-demand-slaves-in-dockers) on stack overflow could also contain some help in this regard. Basically spins-up a new docker image on demand.
  
  Another possible way with your current setup, make sure the build always ends with a shutdown of the image. This way the next job will be sure to use a fresh image as it *should* never survive the build. You could even test fort his situation and fail the build outright if you detect the image was re-cycled between builds rather than re-launched.
  
  > **Comments:**
  > **username_1**: "I still dont see how starting an agent creates a clean image." VMs with readonly root keep the FS in memory and on cycling anything not part of the readonly image are lost.  I have a similar use-case. I have a writable overlay image for my agents with a backing file that contains the OS and everything else. Once a build is complete, I want to shutdown the agent so that hooks in libvirt can run and re-provision the writable overlay.  So, to answer the unasked question, there are a few ways that restarting gets a clean environment.  
  > **username_2**: >VMs with readonly root keep the FS in memory and on cycling anything not part of the readonly image are lost.  ... Ha! interesting yes !  thanks for the info  
  
  ---
  
  ### Answer by username_3 on 2018-08-25. Score: 2
  
  Slave restarts the agent itself after each build? You can use [Conditional BuildStep](https://wiki.jenkins.io/display/JENKINS/Conditional+BuildStep+Plugin) plugin to restart it on a defined condition.
  
  
  ---
  
  