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
