Discussion:
What is the correct use of the "Subversion revision" option for the "Trigger parameterized build on other projects" plugin?
Jeremy
2011-02-09 20:23:03 UTC
Permalink
Hi all,

I'm running daily builds on Hudson 1.385, and what I'm trying to do is
make sure that all my daily-build task's downstream jobs get built
from the exact same SVN revision, even if somebody checks in a commit
to SVN during the daily-build period.

To do that, I have my daily-build (upstream) task checkout a (small)
folder from my SVN repository, and then have it launch the downstream
jobs via the "Trigger parameterized build on other projects" option,
which the "Subversion revision" parameter specified in the "Add
Parameters" section.

However, when I test the daily-build process (by triggering the daily-
build job, and then doing some SVN commits during the period after one
downstream task has done its SVN checkout, but before another one
has), I still see that the resulting artifacts are built from
different SVN revision tags.

My question is, am I doing this the right way? Is there anything I
need to specify in the downstream builds to let them know they should
be using the daily-build job's SVN_REVISION value for the svn
checkout, and not just checkout from HEAD?

Thanks,
Jeremy
Tom Huybrechts
2011-02-09 21:00:30 UTC
Permalink
check out http://wiki.jenkins-ci.org/display/JENKINS/Tracking+SVN+Plugin
Post by Jeremy
Hi all,
I'm running daily builds on Hudson 1.385, and what I'm trying to do is
make sure that all my daily-build task's downstream jobs get built
from the exact same SVN revision, even if somebody checks in a commit
to SVN during the daily-build period.
To do that, I have my daily-build (upstream) task checkout a (small)
folder from my SVN repository, and then have it launch the downstream
jobs via the "Trigger parameterized build on other projects" option,
which the "Subversion revision" parameter specified in the "Add
Parameters" section.
However, when I test the daily-build process (by triggering the daily-
build job, and then doing some SVN commits during the period after one
downstream task has done its SVN checkout, but before another one
has), I still see that the resulting artifacts are built from
different SVN revision tags.
My question is, am I doing this the right way? Is there anything I
need to specify in the downstream builds to let them know they should
be using the daily-build job's SVN_REVISION value for the svn
checkout, and not just checkout from HEAD?
Thanks,
Jeremy
Jeremy
2011-02-10 01:56:08 UTC
Permalink
Hi Tom,

I looked at the Tracking SVN Plugin, but from what I can tell it won't
More than one module may be used, and the revision tracking will happen for any URL in this project that exactly matches the tracked project. For all other modules, the latest revision will be used.
The problem is, some of my various downstream build jobs are checking
out code from different URLs (i.e. different sub-directories inside
the same SVN repository). So according to documentation, at least
some of my builds would get checked out of HEAD instead of from the
upstream revision ID.

Let me know if I am misunderstanding how the Plugin works, though.

-Jeremy
check outhttp://wiki.jenkins-ci.org/display/JENKINS/Tracking+SVN+Plugin
JOHNSTON, Rob
2011-02-10 02:14:49 UTC
Permalink
DomainKey-Signature: a=rsa-sha1; c=nofws;
d=googlegroups.com; s�ta;
h=x-beenthere:received-spf:x-viruschecked:x-env-sender:x-msg-ref
:x-starscan-version:x-originating-ip:from:to:date:subject
:thread-topic:thread-index:message-id:references:in-reply-to
:accept-language:x-ms-has-attach:x-ms-tnef-correlator:acceptlanguage
:mime-version:x-original-sender:x-original-authentication-results
:reply-to:precedence:mailing-list:list-id:list-post:list-help
:list-archive:sender:list-subscribe:list-unsubscribe
:content-language:content-type:content-transfer-encoding;
b,Rtwc0wvc0AY2xw8jnez5yTaeNotwTlOkufxBeCof81wlsfHkCeu28yI5sMdbsP6J
D4Rm5rUG70xk7k2PCwZuzHUhoLU8/zZrWZSAZwSjeSDKJHqybbzKoODLbSkWNS6b540R
ixKesC6/XJk7SAyOpHfHqAK7413MH0A8H9uOQReceived: by 10.217.1.198 with SMTP id n48mr4619611wes.19.1297304128448;
Wed, 09 Feb 2011 18:15:28 -0800 (PST)
X-BeenThere: jenkinsci-users-/***@public.gmane.org
Received: by 10.216.162.73 with SMTP id x51ls315882wek.3.p; Wed, 09 Feb 2011
18:15:25 -0800 (PST)
Received: by 10.216.88.135 with SMTP id a7mr1264634wef.5.1297304125477;
Wed, 09 Feb 2011 18:15:25 -0800 (PST)
Received: by 10.216.88.135 with SMTP id a7mr1264633wef.5.1297304125430;
Wed, 09 Feb 2011 18:15:25 -0800 (PST)
Received: from mail144.messagelabs.com (mail144.messagelabs.com [216.82.254.51])
by gmr-mx.google.com with ESMTPS id p4si112953weq.12.2011.02.09.18.15.24
(version=TLSv1/SSLv3 cipher=OTHER);
Wed, 09 Feb 2011 18:15:25 -0800 (PST)
Received-SPF: pass (google.com: domain of Rob.JOHNSTON-***@public.gmane.org designates 216.82.254.51 as permitted sender) client-ip!6.82.254.51;
X-VirusChecked: Checked
X-Env-Sender: Rob.JOHNSTON-***@public.gmane.org
X-Msg-Ref: server-10.tower-144.messagelabs.com!1297303892!77302671!136
X-StarScan-Version: 6.2.9; banners=-,-,-
X-Originating-IP: [203.0.223.249]
Received: (qmail 3529 invoked from network); 10 Feb 2011 02:15:23 -0000
Received: from mail2.suncorpmetway.com.au (HELO PBNEMSXEDGE2002.workgroup.com) (203.0.223.249)
by server-10.tower-144.messagelabs.com with RC4-SHA encrypted SMTP; 10 Feb 2011 02:15:23 -0000
Received: from PBNEMSX4704.int.corp.sun (10.70.165.65) by
PBNEMSXEDGE2002.workgroup.com (192.168.127.216) with Microsoft SMTP Server
(TLS) id 8.1.393.1; Thu, 10 Feb 2011 12:15:13 +1000
Received: from PBNECRMSX4720.int.corp.sun ([10.70.165.130]) by
PBNEMSX4704.int.corp.sun ([10.70.165.65]) with mapi; Thu, 10 Feb 2011
12:14:52 +1000
Thread-Topic: What is the correct use of the "Subversion revision" option
for the "Trigger parameterized build on other projects" plugin?
Thread-Index: AcvIlzrdOIt2lSLsTWCKodjNleDi9wAMEFog
In-Reply-To: <7e0cfdf5-fa85-4a02-9741-56f6ac1e0f5b-T1m9eTvu/Xk9qo3wXnHHrmB/***@public.gmane.org>
Accept-Language: en-US, en-AU
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US, en-AU
X-Original-Sender: rob.johnston-***@public.gmane.org
X-Original-Authentication-Results: gmr-mx.google.com; spf=pass (google.com:
domain of Rob.JOHNSTON-***@public.gmane.org designates 216.82.254.51 as permitted
sender) smtp.mail=Rob.JOHNSTON-***@public.gmane.org
Precedence: list
Mailing-list: list jenkinsci-users-/***@public.gmane.org; contact jenkinsci-users+owners-/***@public.gmane.org
List-ID: <jenkinsci-users.googlegroups.com>
List-Post: <http://groups.google.com/group/jenkinsci-users/post?hl=en_US>, <mailto:jenkinsci-users-/***@public.gmane.org>
List-Help: <http://groups.google.com/support/?hl=en_US>, <mailto:jenkinsci-users+help-/***@public.gmane.org>
List-Archive: <http://groups.google.com/group/jenkinsci-users?hl=en_US>
Sender: jenkinsci-users-/***@public.gmane.org
List-Subscribe: <http://groups.google.com/group/jenkinsci-users/subscribe?hl=en_US>,
<mailto:jenkinsci-users+subscribe-/***@public.gmane.org>
List-Unsubscribe: <http://groups.google.com/group/jenkinsci-users/subscribe?hl=en_US>,
<mailto:jenkinsci-users+unsubscribe-/***@public.gmane.org>
Content-Language: en-US
Archived-At: <http://permalink.gmane.org/gmane.comp.java.jenkins.user/181>

Hi Jeremy

I don't know if this is the correct way to do it, but it's working for us.

Add a parameter to each of your sub jobs, named "SVN_REVISION".

Add "@${SVN_REVISION}" to the end of the job's Repository URL, so it might look something like this:

https://path.to.svn/repsoitory/some/path@${SVN_REVISION}

Now, when your sub job does an update, the svn url you see on the console output should be something like "https://path.to.svn/repsoitory/***@12345"

Hope that helps

Rob

-----Original Message-----
From: jenkinsci-users-/***@public.gmane.org [mailto:jenkinsci-***@googlegroups.com] On Behalf Of Jeremy
Sent: Thursday, 10 February 2011 6:23 AM
To: Jenkins Users
Subject: What is the correct use of the "Subversion revision" option for the "Trigger parameterized build on other projects" plugin?

Hi all,

I'm running daily builds on Hudson 1.385, and what I'm trying to do is
make sure that all my daily-build task's downstream jobs get built
from the exact same SVN revision, even if somebody checks in a commit
to SVN during the daily-build period.

To do that, I have my daily-build (upstream) task checkout a (small)
folder from my SVN repository, and then have it launch the downstream
jobs via the "Trigger parameterized build on other projects" option,
which the "Subversion revision" parameter specified in the "Add
Parameters" section.

However, when I test the daily-build process (by triggering the daily-
build job, and then doing some SVN commits during the period after one
downstream task has done its SVN checkout, but before another one
has), I still see that the resulting artifacts are built from
different SVN revision tags.

My question is, am I doing this the right way? Is there anything I
need to specify in the downstream builds to let them know they should
be using the daily-build job's SVN_REVISION value for the svn
checkout, and not just checkout from HEAD?

Thanks,
Jeremy

This e-mail is sent by Suncorp Group Limited ABN 66 145 290 124 or one of its related entities "Suncorp".
Suncorp may be contacted at Level 18, 36 Wickham Terrace, Brisbane or on 13 11 55 or at suncorp.com.au.
The content of this e-mail is the view of the sender or stated author and does not necessarily reflect the view of Suncorp. The content, including attachments, is a confidential communication between Suncorp and the intended recipient. If you are not the intended recipient, any use, interference with, disclosure or copying of this e-mail, including attachments, is unauthorised and expressly prohibited. If you have received this e-mail in error please contact the sender immediately and delete the e-mail and any attachments from your system.
If this e-mail constitutes a commercial message of a type that you no longer wish to receive please reply to this e-mail by typing Unsubscribe in the subject line.
Jeremy
2011-02-10 03:46:37 UTC
Permalink
Thanks Rob, that was helpful advice.

I followed your recommendations, but it still didn't work until I made
another change as well: In the daily-build (upstream) job's "Trigger
parameterized build on other projects" area, I removed the "Subversion
revision" parameter and instead added a "Predefined Parameters"
parameter. In the text box for that I entered the text:

SVN_REVISION=${SVN_REVISION}

.... and that finally seems to do the trick. Of course, the upstream
build only gets the correct SVN revision number if I have it check out
the entire SVN repository... but I can live with that.

Thanks again,
Jeremy
Post by JOHNSTON, Rob
Hi Jeremy
I don't know if this is the correct way to do it, but it's working for us.
Add a parameter to each of your sub jobs, named "SVN_REVISION".
Hope that helps
Rob
-----Original Message-----
Sent: Thursday, 10 February 2011 6:23 AM
To: Jenkins Users
Subject: What is the correct use of the "Subversion revision" option for the "Trigger parameterized build on other projects" plugin?
Hi all,
I'm running daily builds on Hudson 1.385, and what I'm trying to do is
make sure that all my daily-build task's downstream jobs get built
from the exact same SVN revision, even if somebody checks in a commit
to SVN during the daily-build period.
To do that, I have my daily-build (upstream) task checkout a (small)
folder from my SVN repository, and then have it launch the downstream
jobs via the "Trigger parameterized build on other projects" option,
which the "Subversion revision" parameter specified in the "Add
Parameters" section.
However, when I test the daily-build process (by triggering the daily-
build job, and then doing some SVN commits during the period after one
downstream task has done its SVN checkout, but before another one
has), I still see that the resulting artifacts are built from
different SVN revision tags.
My question is, am I doing this the right way?  Is there anything I
need to specify in the downstream builds to let them know they should
be using the daily-build job's SVN_REVISION value for the svn
checkout, and not just checkout from HEAD?
Thanks,
Jeremy
This e-mail is sent by Suncorp Group Limited ABN 66 145 290 124 or one of its related entities "Suncorp".
Suncorp may be contacted at Level 18, 36 Wickham Terrace, Brisbane or on 13 11 55 or at suncorp.com.au.
The content of this e-mail is the view of the sender or stated author and does not necessarily reflect the view of Suncorp. The content, including attachments, is a confidential communication between Suncorp and the intended recipient. If you are not the intended recipient, any use, interference with, disclosure or copying of this e-mail, including attachments, is unauthorised and expressly prohibited. If you have received this e-mail in error please contact the sender immediately and delete the e-mail and any attachments from your system.
If this e-mail constitutes a commercial message of a type that you no longer wish to receive please reply to this e-mail by typing Unsubscribe in the subject line.
Tom Huybrechts
2011-02-10 19:41:32 UTC
Permalink
That's correct. To handle that with the plugin, you would need to check out
all svn modules in the upstream job, even if you don't need them...
Post by Jeremy
Hi Tom,
I looked at the Tracking SVN Plugin, but from what I can tell it won't
More than one module may be used, and the revision tracking will happen
for any URL in this project that exactly matches the tracked project. For
all other modules, the latest revision will be used.
The problem is, some of my various downstream build jobs are checking
out code from different URLs (i.e. different sub-directories inside
the same SVN repository). So according to documentation, at least
some of my builds would get checked out of HEAD instead of from the
upstream revision ID.
Let me know if I am misunderstanding how the Plugin works, though.
-Jeremy
check outhttp://wiki.jenkins-ci.org/display/JENKINS/Tracking+SVN+Plugin
Loading...