Restricting builds from running at certain times of the day

[Ari Maniatis]

I have a Jenkins server which is triggered by the usual svn hooks on every commit. However I also have some very long running jobs which I only want to run overnight, when we have spare CPU capacity.

For those jobs I have unticked the option:

[ ] Trigger builds remotely (e.g., from scripts)

But it would appear that that option does not apply to the subversion trigger URL (
/server/subversion/${UUID}/notifyCommit?rev=$REV ). How do I ensure that some jobs are NOT triggered by the subversion hook along with all the others? I want them to run on a timed schedule or polling instead.

[Mandeville, Rob]

Let the jobs trigger when they will.  But force the jobs to run only on certain nodes (such as by using a label).  Then, when configuring  the nodes, set the availability to “Take this slave on-line according to a schedule”.  Now, when you don’t want the jobs to be running, they’ll queue up waiting for a node they can run on to fire up.

 

--Rob

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Ari Maniatis
Sent: Wednesday, June 13, 2012 6:15 AM
To: [hidden email]
Subject: Restricting builds from running at certain times of the day

 

I have a Jenkins server which is triggered by the usual svn hooks on every commit. However I also have some very long running jobs which I only want to run overnight, when we have spare CPU capacity.

For those jobs I have unticked the option:

[ ] Trigger builds remotely (e.g., from scripts)

But it would appear that that option does not apply to the subversion trigger URL (
/server/subversion/${UUID}/notifyCommit?rev=$REV ). How do I ensure that some jobs are NOT triggered by the subversion hook along with all the others? I want them to run on a timed schedule or polling instead.

The information in this message is for the intended recipient(s) only and may be the proprietary and/or confidential property of Litle & Co., LLC, and thus protected from disclosure. If you are not the intended recipient(s), or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any use, dissemination, distribution or copying of this communication is prohibited. If you have received this communication in error, please notify Litle & Co. immediately by replying to this message and then promptly deleting it and your reply permanently from your computer.

[Ari Maniatis]

Thanks for that idea. Unfortunately in my case I don't have enough slaves to set it up like that (I guess unless I create two slaves on the same physical machine)...

I don't really understand what "[ ] Trigger builds remotely (e.g., from scripts)" is supposed to do. Why can't I switch off subversion hooks using this? Is this a bug I should file or was that intended for something else?

Ari


On Wednesday, June 13, 2012 11:23:10 PM UTC+10, Mandeville, Rob wrote:

Let the jobs trigger when they will.  But force the jobs to run only on certain nodes (such as by using a label).  Then, when configuring  the nodes, set the availability to “Take this slave on-line according to a schedule”.  Now, when you don’t want the jobs to be running, they’ll queue up waiting for a node they can run on to fire up.

 

--Rob

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Ari Maniatis
Sent: Wednesday, June 13, 2012 6:15 AM
To: [hidden email]
Subject: Restricting builds from running at certain times of the day

 

I have a Jenkins server which is triggered by the usual svn hooks on every commit. However I also have some very long running jobs which I only want to run overnight, when we have spare CPU capacity.

For those jobs I have unticked the option:

[ ] Trigger builds remotely (e.g., from scripts)

But it would appear that that option does not apply to the subversion trigger URL (
/server/subversion/${UUID}/notifyCommit?rev=$REV ). How do I ensure that some jobs are NOT triggered by the subversion hook along with all the others? I want them to run on a timed schedule or polling instead.

The information in this message is for the intended recipient(s) only and may be the proprietary and/or confidential property of Litle & Co., LLC, and thus protected from disclosure. If you are not the intended recipient(s), or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any use, dissemination, distribution or copying of this communication is prohibited. If you have received this communication in error, please notify Litle & Co. immediately by replying to this message and then promptly deleting it and your reply permanently from your computer.

[Les Mikesell]

On Sat, Jun 16, 2012 at 1:40 AM, Ari Maniatis
<[hidden email]> wrote:
> Thanks for that idea. Unfortunately in my case I don't have enough slaves to
> set it up like that (I guess unless I create two slaves on the same physical
> machine)...

Why not get rid of the subversion hook if you don't want it to work?
Jenkins can poll for changes at reasonable rates and you can control
the scheduling.   Or, put the logic of what subversion paths you want
to build instantly on every commit vs. the ones you don't into the
hook script.

--
   Les Mikesell
     [hidden email]

[Mandeville, Rob]

You are correct that this might need multiple slaves per host to do that.  This isn’t a big deal to do, just make sure that they have different root directories.  At my shop, where a build and test cycle takes up an entire Unix account, we have several slaves per host, each one on a different account.

 

The ‘Trigger builds remotely’ feature sets up a URL so that you can trigger a build with an HTTP request.  That means that a script can use something like wget or curl to launch a Jenkins build.  Even without this feature, you can launch builds using the Jenkins CLI (running a JAR file that you can get from your Jenkins server); see https://wiki.jenkins-ci.org/display/JENKINS/Jenkins+CLI for details.  I’m not sure if this relates to triggering builds at certain times.

 

--Rob

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Ari Maniatis
Sent: Saturday, June 16, 2012 2:40 AM
To: [hidden email]
Subject: Re: Restricting builds from running at certain times of the day

 

Thanks for that idea. Unfortunately in my case I don't have enough slaves to set it up like that (I guess unless I create two slaves on the same physical machine)...

I don't really understand what "[ ] Trigger builds remotely (e.g., from scripts)" is supposed to do. Why can't I switch off subversion hooks using this? Is this a bug I should file or was that intended for something else?

Ari


On Wednesday, June 13, 2012 11:23:10 PM UTC+10, Mandeville, Rob wrote:

Let the jobs trigger when they will.  But force the jobs to run only on certain nodes (such as by using a label).  Then, when configuring  the nodes, set the availability to “Take this slave on-line according to a schedule”.  Now, when you don’t want the jobs to be running, they’ll queue up waiting for a node they can run on to fire up.

 

--Rob

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Ari Maniatis
Sent: Wednesday, June 13, 2012 6:15 AM
To: [hidden email]
Subject: Restricting builds from running at certain times of the day

 

I have a Jenkins server which is triggered by the usual svn hooks on every commit. However I also have some very long running jobs which I only want to run overnight, when we have spare CPU capacity.

For those jobs I have unticked the option:

[ ] Trigger builds remotely (e.g., from scripts)

But it would appear that that option does not apply to the subversion trigger URL (
/server/subversion/${UUID}/notifyCommit?rev=$REV ). How do I ensure that some jobs are NOT triggered by the subversion hook along with all the others? I want them to run on a timed schedule or polling instead.

The information in this message is for the intended recipient(s) only and may be the proprietary and/or confidential property of Litle & Co., LLC, and thus protected from disclosure. If you are not the intended recipient(s), or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any use, dissemination, distribution or copying of this communication is prohibited. If you have received this communication in error, please notify Litle & Co. immediately by replying to this message and then promptly deleting it and your reply permanently from your computer.