ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carlton Brown <>
Subject Re: repeatable integration builds?
Date Thu, 22 Jul 2010 20:30:12 GMT
  You just need to make sure you retain a copy of the resolved ivy 
file.   I've taken 2 approaches to this.   I'm assuming the modules A 
and B don't export any dependencies to other modules, otherwise you'd 
already have your resolved ivy files in your repositories.

1:  Publish modules A and B.   It may seem wasteful to publish modules 
that don't actually export any dependencies, but I've found it very 
handy as a reference when I want to use ivy:install to "promote" a 
module and all its dependencies from an integration repository to a 
production repository.   I've even gone as far as to have the build 
publish HTML dependency reports so that anyone can browse any module's 
dependencies without having to manually regenerate them.

2:  Use ivy:deliver to generate the resolved ivy file, then commit it 
into the svn tag in place of the unresolved ivy.xml.   This sort of 
breaks the notion that svn tags are immutable, but it's very elegant 
from a reproducibility point of view because anyone can check out that 
svn tag and be sure they'll get exactly the same dependencies that were 
used to build that tag.

Hope this helps,

On 7/22/2010 3:36 PM, Bailey, Darragh wrote:
> 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 projects that we are using.
in particular the section "Dealing with integration versions".
> Now I need to start handling the inter project dependencies a bit better, particular
as the number of components increase. In the section "Dealing with integration versions",
I'm leaning towards using the second option "automatically 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 that falling
down if someone wishes to build older releases in order to retest 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 integration 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
> i) include the svn revision as part of the version number of each integration release
and have the continuous integration software set the svn revision 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 numerically increasing repository revision strings)
> ii) or when rebuilding older builds create a temporary repository that is used instead
and have all components build and publish to this repository. Thus the components with dependencies
can just reference the latest.integration release from the temporary repository which will
be guarenteed to include binaries only from the same source repository revision
> Any other options, or am I missing something in ivy that will make this easier to handle?
> --
> Regards,
> Darragh Bailey
> Systems Software Engineer
> Hewlett Packard Galway Ltd.
> Postal Address:    Hewlett Packard Galway Limited, Ballybrit Business Park, Galway
> Registered Office: Hewlett Packard Galway Limited, 63-74 Sir John Rogerson's Quay Dublin
> Registered Number: 361933

View raw message