repeatable integration builds?

["Bailey, Darragh" <db...@hp.com>]

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. http://ant.apache.org/ivy/history/latest-milestone/bestpractices.html 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 2
Registered Number: 361933 

Re: repeatable integration builds?

[Carlton Brown <cb...@gmail.com>]

  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,
Carlton

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. http://ant.apache.org/ivy/history/latest-milestone/bestpractices.html 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 2
> Registered Number: 361933
>
>