Mailing-List: contact ivy-user-help@ant.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ivy-user@ant.apache.org
Received-SPF: pass (athena.apache.org: local policy)
From: "Bailey, Darragh" <dbailey@hp.com>
To: "ivy-user@ant.apache.org" <ivy-user@ant.apache.org>
Date: Thu, 22 Jul 2010 19:36:37 +0000
Subject: repeatable integration builds?
Thread-Topic: repeatable integration builds?
Thread-Index: Acsp1TNxi1m/fnFqTeyF6VCaRZ875Q==
Message-ID: 
 <FF452E17060D614D89BF7FD3A07A88334FAADF87D6@GVW1115EXC.americas.hpqcorp.net>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0


Wondering how people setup for repeatable integration builds using ivy.

I'm currently reading through some of the documentation that I skimmed over=
 previously when I put together a simple mirror repository for external pro=
jects that we are using. http://ant.apache.org/ivy/history/latest-milestone=
/bestpractices.html in particular the section "Dealing with integration ver=
sions".=20

Now I need to start handling the inter project dependencies a bit better, p=
articular as the number of components increase. In the section "Dealing wit=
h integration versions", I'm leaning towards using the second option "autom=
atically create a new version for each", however I'm not sure how to handle=
 making sure that the version constraints put in place allow for repeatable=
 builds.

For head of tree builds, using 'latest.integration' seems fine. But I see t=
hat falling down if someone wishes to build older releases in order to rete=
st bugs.

Example
SVN tree @ revision 2000
QA need a build of revision 900 to test for a particular bug, the existing =
one has been pruned, so will need a fresh build
Tree consists of components A, B and C where both A and B rely on C. Build =
order is something that I'll have to work out with the continuous integrati=
on software I'm using.
How do I ensure that that components A & B, don't use a build of C that is =
newer that svn revision 900?


It seems that I'm likely to either=20
i) include the svn revision as part of the version number of each integrati=
on release and have the continuous integration software set the svn revisio=
n used as a property at build time. And code the version constratins to use=
 this revision as a max limit? (seems very svn centric as it relies on nume=
rically increasing repository revision strings)
ii) or when rebuilding older builds create a temporary repository that is u=
sed instead and have all components build and publish to this repository. T=
hus the components with dependencies can just reference the latest.integrat=
ion release from the temporary repository which will be guarenteed to inclu=
de binaries only from the same source repository revision


Any other options, or am I missing something in ivy that will make this eas=
ier to handle?


--
Regards,
Darragh Bailey

Systems Software Engineer
Hewlett Packard Galway Ltd.

Postal Address:=A0=A0=A0 Hewlett Packard Galway Limited, Ballybrit Business=
 Park, Galway
Registered Office: Hewlett Packard Galway Limited, 63-74 Sir John Rogerson'=
s Quay Dublin 2
Registered Number: 361933=20