My apologies. My description was wrong. It makes it sound simpler than it
actually is, or at least it sounds simpler than the technique I'm actually
using to reboot a slave agent.
I reviewed the Jenkins job which I have that reboots a Windows machine in
hopes of reducing the number of times a job will fail due to "busy files".
In that job, I have an ant script which schedules a reboot soon after the
current time. That allows the job which schedules the reboot to complete
successfully.
It also requires that a subsequent job be configured to delay its start
long enough for the computer to reboot and reconnect the Jenkins slave. I
suspect you'll need to make guesses and watch behavior to decide the length
of that delay.
The build.xml file for the reboot task contains this:
<!-- StackOverflow special thanks for this technique -->
<scriptdef name="generateguid" language="javascript">
<attribute name="property" />
<![CDATA[project.setProperty( attributes.get( "property" ),
java.util.UUID.randomUUID() );]]>
</scriptdef>
<target name="reboot" description="Reboot this computer">
<tstamp>
<format property="current.time" pattern="HH:mm"/>
</tstamp>
<tstamp>
<!-- Schedule reboot 1 minute from now -->
<format property="reboot.time" pattern="HH:mm" offset="2"
unit="minute"/>
</tstamp>
<echo>It is ${current.time}, rebooting at ${reboot.time}</echo>
<generateguid property="guid" />
<exec osfamily="windows" executable="schtasks.exe" failonerror="true">
<arg value="/Create"/>
<arg value="/RU"/> <arg value="Reboot"/> <!-- user name of an
Administrator user -->
<arg value="/RP"/> <arg value=""/> <!-- insert the password of your
"Reboot" user -->
<arg value="/SC"/> <arg value="Once"/>
<arg value="/ST"/> <arg value="${reboot.time}"/>
<arg value="/TN"/> <arg value="Reboot-${guid}"/>
<arg value="/TR"/> <arg value="shutdown /r /t 2"/>
</exec>
</target>
Mark Waite
On Fri, Apr 24, 2015 at 1:28 AM Ankit Singhal <ankising...@gmail.com> wrote:
> Hi Mark,
>
> Thanks for the reply. Can you please help me in detailing the steps of
> doing it. I tried following
>
>
> - Created a build-flow name " Start test"
> - After that created 3 freestyle projects.
> - Project1 : Before Reboot
> - Command: echo "Before Reboot"
> - Project 2 : Reboot
> - Command : shutdown /r /t 0
> - Project 3 : After reboot
> - Command : echo "after reboot"
> - Then run the above 3 projects from build-flow
> - The "Start test" project fails after project 2 runs as the node goes
> offline.
>
> Is there anyway to wait project 3 , till the node comes back online.
>
> Regards
> Ankit
>
>
>
>
> On Friday, April 24, 2015 at 7:22:32 AM UTC+5:30, Mark Waite wrote:
>
>> When I've needed to run something on a freshly booted machine,
>> particularly as part of a series of jobs, I've generally been able to do
>> that by partitioning the work into multiple jobs, with the job which must
>> execute on the newly booted slave being configured to run on the slave.
>>
>> A single job can't run successfully on the slave node being rebooted
>> (during the reboot), because, as you note, it will fail the job. Multiple
>> jobs allow you to have the job wait for the slave agent to become
>> available, then it immediately starts the job.
>>
>> On Thu, Apr 23, 2015 at 12:27 PM Ankit Singhal <ankis...@gmail.com>
>> wrote:
>>
> Hi
>>>
>>> I need some help in solving the reboot problem.
>>>
>>> The Workflow is as follows:
>>>
>>> 1) Project 1 creates a Windows Installable package.
>>> 2) Project 2 is called once the Project1 is completed and Package is
>>> pushed to Slave associated with Project 2.
>>> 3) Project 2 now runs some commands on Slave 2
>>>
>>> Command 1 : Install Package on Slave 2
>>> Command 2 : Run some commands to enable the software.
>>> Command 3 : Reboot the machine.
>>>
>>> 4) This might break the Job running in Project 2.
>>> 5) After reboot , we need to run some more commands on Slave 2 to run
>>> some more tests.
>>> 6) After tests are completed , the full Job in Project 2 is done.
>>>
>>> In nutshell , how to handle the reboot scenario , so that the job is not
>>> broken in between.
>>>
>>> Regards
>>> Ankit
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Jenkins Users" group.
>>>
>> To unsubscribe from this group and stop receiving emails from it, send an
>>> email to jenkinsci-use...@googlegroups.com.
>>
>>
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/jenkinsci-users/d2f0f06b-5dcf-4875-92b0-30f0c8dbbe04%40googlegroups.com
>>> <https://groups.google.com/d/msgid/jenkinsci-users/d2f0f06b-5dcf-4875-92b0-30f0c8dbbe04%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-users/d5548546-f61d-4476-981c-245669283299%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-users/d5548546-f61d-4476-981c-245669283299%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
--
You received this message because you are subscribed to the Google Groups
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-users/CAO49JtFPK1PP6Rsx1BhEc8t1ZKgN3McXSvQ5zF9DoWDD33Hkgg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
