ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bieringer, Dominik" <>
Subject How to promote a set of artifacts
Date Thu, 05 Feb 2009 14:05:02 GMT

I've just started using ivy and read the following on the best practices page:


Imagine you have a customer which comes on a monday morning and asks your latest version of
your software, for testing or demonstration purpose. Obviously he needs it for the afternoon
:-) Now if you have a continuous integration process and a good tracking of your changes and
your artifacts, it may occur that you are actually able to fulfill his request without needing
the use of a dolorean to give you some more time :-) But it may occur also that your latest
version stable enough to be used for the purpose of the customer was actually built a few
days ago, because the very latest just break a feature or introduce a new one you don't want
to deliver. In this case, you can deliver this 'stable' integration build if you want, but
be sure that a few days, or weeks, or even months later, the customer will ask for a bug fix
on this demo only version. Why? Because it's a customer, and we all know how they are :-)

So, with a build promotion feature of any build in your repository, the solution would be
pretty easy: when the customer ask for the version, you not only deliver the integration build,
but you also promote it to a milestone status, for example. this promotion indicates that
you should keep track of this version in a long period, to be able to come back to it and
create a branch if needed.

Unfortunately Ivy does not by its own allow to have such reproducible builds out of the box,
simply because Ivy is a dependency manager, not a build tool. But if you publish only versions
with a distinct name and use Ivy features like versions constraint replacement during the
publication or recursive delivery of modules, it can really help.


What I have in place already is a build system which publishes the artifacts and a resolved
ivy file to a repository. Version identifiers for those builds are generated (the default
date time pattern provided by ivy). Builds are started automatically whenever a commit is
performed or a developer starts the build manually on the build server. Developers take a
look at the build results and, in case they want to release a build, send a release request
(mail) to another department within our company. There the build will get checked and might
get approved. In case a build gets approved, I want to somehow update the ivy file in the
repository to: 1) use the correct revision provided on qa approval step 2) change the status
from integration to release. I guess that is exactly what is meant by "promote a build" in
the text above.

My question is now how to actually promote a build. What I already thought of is writing some
scripts to update the XML file, but those scripts would be dependent on the actual file system
structure of the repository, which I want to prevent if possible. Are there any ivy tasks
to do such a  thing? I found an ivy task called "install" which is performing a very similar
work... I thought of using it with the same resolver set as source and target, but there are
no attributes to update the revision and status properties of an ivy descriptor during the
install process...

Any help would be appreciated.


Dominik Bieringer | Internal Tools & Test Automation | GoldenSource Corporation | Skype:
dominik.bieringer | T: +43 7229 76656 44 |<>

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message