SVN trigger for some builds, poll for others?

[Zac Thompson]

I have projects with CI builds, triggered by polling SVN every few minutes.

I also run a once-nightly Sonar analysis of each project, also
triggered by polling SVN.  These are a separate set of jobs from the
ones above.  These will only run once per day, and only if the code
has changed in the last day.

Ideally the CI builds would run as soon as the change was made. I know
I can set up a post-commit hook to trigger the CI build from each SVN
repo, as documented here:

https://wiki.jenkins-ci.org/display/JENKINS/Subversion+Plugin

... the problem is that this will also trigger the expensive Sonar
analysis jobs ("The net effect is as if polling happens out of their
usual cycles.").

It seems like I have only three choices:

1) Continue to use SCM polling everywhere, and have to wait for CI
builds until the next polling cycle after every change
2) Use a post-commit hook everywhere, and have to schedule my Sonar
jobs to run every night whether there was a change or not
3) Maintain a custom post-commit hook for every repo that knows about
the specific set of relevant jobs for that codebase

All of these options seem like poor compromises, although #2 seems
like the best choice for me.

Is there any other option?  How do other people co-ordinate the need
for different jobs & schedules for each repo?  Is there a way to
configure a build to "poll, but ignore notifyCommit posts"?

Zac

[Didier Durand]

Hi Zac,

For the nightly Sonar analysis, why don't you just use a time-
triggered build ?

regards

didier

On Jun 6, 1:52 am, Zac Thompson <[hidden email]> wrote:

> I have projects with CI builds, triggered by polling SVN every few minutes.
>
> I also run a once-nightly Sonar analysis of each project, also
> triggered by polling SVN.  These are a separate set of jobs from the
> ones above.  These will only run once per day, and only if the code
> has changed in the last day.
>
> Ideally the CI builds would run as soon as the change was made. I know
> I can set up a post-commit hook to trigger the CI build from each SVN
> repo, as documented here:
>
> https://wiki.jenkins-ci.org/display/JENKINS/Subversion+Plugin
>
> ... the problem is that this will also trigger the expensive Sonar
> analysis jobs ("The net effect is as if polling happens out of their
> usual cycles.").
>
> It seems like I have only three choices:
>
> 1) Continue to use SCM polling everywhere, and have to wait for CI
> builds until the next polling cycle after every change
> 2) Use a post-commit hook everywhere, and have to schedule my Sonar
> jobs to run every night whether there was a change or not
> 3) Maintain a custom post-commit hook for every repo that knows about
> the specific set of relevant jobs for that codebase
>
> All of these options seem like poor compromises, although #2 seems
> like the best choice for me.
>
> Is there any other option?  How do other people co-ordinate the need
> for different jobs & schedules for each repo?  Is there a way to
> configure a build to "poll, but ignore notifyCommit posts"?
>
> Zac

[Zac Thompson]

Hi Didier, I can use a scheduled build for Sonar (option 2) but then
all the Sonar jobs will run every night even if there is no change.
It's not a big problem, but it pollutes the Sonar history with
repeated data.

On Sun, Jun 5, 2011 at 9:30 PM, Didier Durand <[hidden email]> wrote:

> Hi Zac,
>
> For the nightly Sonar analysis, why don't you just use a time-
> triggered build ?
>
> regards
>
> didier
>
> On Jun 6, 1:52 am, Zac Thompson <[hidden email]> wrote:
>> I have projects with CI builds, triggered by polling SVN every few minutes.
>>
>> I also run a once-nightly Sonar analysis of each project, also
>> triggered by polling SVN.  These are a separate set of jobs from the
>> ones above.  These will only run once per day, and only if the code
>> has changed in the last day.
>>
>> Ideally the CI builds would run as soon as the change was made. I know
>> I can set up a post-commit hook to trigger the CI build from each SVN
>> repo, as documented here:
>>
>> https://wiki.jenkins-ci.org/display/JENKINS/Subversion+Plugin
>>
>> ... the problem is that this will also trigger the expensive Sonar
>> analysis jobs ("The net effect is as if polling happens out of their
>> usual cycles.").
>>
>> It seems like I have only three choices:
>>
>> 1) Continue to use SCM polling everywhere, and have to wait for CI
>> builds until the next polling cycle after every change
>> 2) Use a post-commit hook everywhere, and have to schedule my Sonar
>> jobs to run every night whether there was a change or not
>> 3) Maintain a custom post-commit hook for every repo that knows about
>> the specific set of relevant jobs for that codebase
>>
>> All of these options seem like poor compromises, although #2 seems
>> like the best choice for me.
>>
>> Is there any other option?  How do other people co-ordinate the need
>> for different jobs & schedules for each repo?  Is there a way to
>> configure a build to "poll, but ignore notifyCommit posts"?
>>
>> Zac

[Bap]

Zac,

So you want 2 jobs, 1 which is kicked off by a post-commit hook, and  
one which polls SCM once per night eg. 03:15 every night "15 3 * * *"

The sonar job will only run if there are changes in subversion since  
it's last run.

Bap.

Quoting Zac Thompson <[hidden email]>:

> Hi Didier, I can use a scheduled build for Sonar (option 2) but then
> all the Sonar jobs will run every night even if there is no change.
> It's not a big problem, but it pollutes the Sonar history with
> repeated data.
>
> On Sun, Jun 5, 2011 at 9:30 PM, Didier Durand  
> <[hidden email]> wrote:
>> Hi Zac,
>>
>> For the nightly Sonar analysis, why don't you just use a time-
>> triggered build ?
>>
>> regards
>>
>> didier
>>
>> On Jun 6, 1:52 am, Zac Thompson <[hidden email]> wrote:
>>> I have projects with CI builds, triggered by polling SVN every few minutes.
>>>
>>> I also run a once-nightly Sonar analysis of each project, also
>>> triggered by polling SVN.  These are a separate set of jobs from the
>>> ones above.  These will only run once per day, and only if the code
>>> has changed in the last day.
>>>
>>> Ideally the CI builds would run as soon as the change was made. I know
>>> I can set up a post-commit hook to trigger the CI build from each SVN
>>> repo, as documented here:
>>>
>>> https://wiki.jenkins-ci.org/display/JENKINS/Subversion+Plugin
>>>
>>> ... the problem is that this will also trigger the expensive Sonar
>>> analysis jobs ("The net effect is as if polling happens out of their
>>> usual cycles.").
>>>
>>> It seems like I have only three choices:
>>>
>>> 1) Continue to use SCM polling everywhere, and have to wait for CI
>>> builds until the next polling cycle after every change
>>> 2) Use a post-commit hook everywhere, and have to schedule my Sonar
>>> jobs to run every night whether there was a change or not
>>> 3) Maintain a custom post-commit hook for every repo that knows about
>>> the specific set of relevant jobs for that codebase
>>>
>>> All of these options seem like poor compromises, although #2 seems
>>> like the best choice for me.
>>>
>>> Is there any other option?  How do other people co-ordinate the need
>>> for different jobs & schedules for each repo?  Is there a way to
>>> configure a build to "poll, but ignore notifyCommit posts"?
>>>
>>> Zac
>

[Zac Thompson]

Bap,

Yes, that's what I want, but in order to do that I need to write the
post-commit hook to launch the job directly, which means I need a
custom hook for every repo.  I would prefer to use the UUID-based
notifyCommit hook as described in the Subversion Plugin docs.  But
then it will trigger the Sonar jobs as well ...

On Mon, Jun 6, 2011 at 2:38 AM, Bap <[hidden email]> wrote:

> Zac,
>
> So you want 2 jobs, 1 which is kicked off by a post-commit hook, and one
> which polls SCM once per night eg. 03:15 every night "15 3 * * *"
>
> The sonar job will only run if there are changes in subversion since it's
> last run.
>
> Bap.
>
> Quoting Zac Thompson <[hidden email]>:
>
>> Hi Didier, I can use a scheduled build for Sonar (option 2) but then
>> all the Sonar jobs will run every night even if there is no change.
>> It's not a big problem, but it pollutes the Sonar history with
>> repeated data.
>>
>> On Sun, Jun 5, 2011 at 9:30 PM, Didier Durand <[hidden email]>
>> wrote:
>>>
>>> Hi Zac,
>>>
>>> For the nightly Sonar analysis, why don't you just use a time-
>>> triggered build ?
>>>
>>> regards
>>>
>>> didier
>>>
>>> On Jun 6, 1:52 am, Zac Thompson <[hidden email]> wrote:
>>>>
>>>> I have projects with CI builds, triggered by polling SVN every few
>>>> minutes.
>>>>
>>>> I also run a once-nightly Sonar analysis of each project, also
>>>> triggered by polling SVN.  These are a separate set of jobs from the
>>>> ones above.  These will only run once per day, and only if the code
>>>> has changed in the last day.
>>>>
>>>> Ideally the CI builds would run as soon as the change was made. I know
>>>> I can set up a post-commit hook to trigger the CI build from each SVN
>>>> repo, as documented here:
>>>>
>>>> https://wiki.jenkins-ci.org/display/JENKINS/Subversion+Plugin
>>>>
>>>> ... the problem is that this will also trigger the expensive Sonar
>>>> analysis jobs ("The net effect is as if polling happens out of their
>>>> usual cycles.").
>>>>
>>>> It seems like I have only three choices:
>>>>
>>>> 1) Continue to use SCM polling everywhere, and have to wait for CI
>>>> builds until the next polling cycle after every change
>>>> 2) Use a post-commit hook everywhere, and have to schedule my Sonar
>>>> jobs to run every night whether there was a change or not
>>>> 3) Maintain a custom post-commit hook for every repo that knows about
>>>> the specific set of relevant jobs for that codebase
>>>>
>>>> All of these options seem like poor compromises, although #2 seems
>>>> like the best choice for me.
>>>>
>>>> Is there any other option?  How do other people co-ordinate the need
>>>> for different jobs & schedules for each repo?  Is there a way to
>>>> configure a build to "poll, but ignore notifyCommit posts"?
>>>>
>>>> Zac
>>
>
>

[Kamal Ahmed]

Is it possible to change the workspace location on jenkin slaves?
Thanks,

[danny staple]

There is an option on the slave node settings under manage hudson for setting this. Alternatively, you can also set a different workspace path for individual jobs.

On 6 June 2011 16:11, Kamal Ahmed <[hidden email]> wrote:

Is it possible to change the workspace location on jenkin slaves?
Thanks,

--
Danny Staple

Director, ODM Solutions Ltd
w: http://www.odmsolutions.co.uk
Blog: http://orionrobots.co.uk/blog1-Danny-Staple

[Ari Maniatis]

I am resurrecting this old thread, since I don't think this was ever settled. I too would like to be able to have two jobs, one which is triggered by an SCM hook and the second one which polls the SCM once a day for Sonar reporting.

Build trigger options are:

Trigger builds remotely (e.g., from scripts) Build periodically Poll SCM Should I tick none of those options for job 1 and "Poll SCM" for job 2? What will prevent job 2 from being triggered by the same SCM hook? Ari