ivy integration with automated build tools

[Shawn Castrianni <Sh...@halliburton.com>]

I have my standalone ivy builds working great such that any developer can build and retrieve dependencies.  However, now I am trying to get automated builds going for continuous integration, scheduled nightly builds, etc.  I was curious what people out there are using.  I always run into the problem of coordinating the automated build systems build numbers and ivy's build numbers.  It would be great if they could be the same such that a developer could look at the automated build website and see builds with numbers that match the number in the ivy repository.

I also see overlap in functionality between ivy and automated build systems with dependency management, publishing, and promotion.  I have all of that working with ivy and am wondering if I just ignore those aspects of the automated build system in favor of ivy?

---
Shawn Castrianni
CM Lead Architect
Landmark
Halliburton Drilling, Evaluation and Digital Solutions Building 2
2101 City West Blvd.
Houston, TX  77042
Work:  713-839-3086
Cell:  832-654-0888
Fax:  713-839-2758

----------------------------------------------------------------------
This e-mail, including any attached files, may contain confidential and privileged information for the sole use of the intended recipient.  Any review, use, distribution, or disclosure by others is strictly prohibited.  If you are not the intended recipient (or authorized to receive information for the intended recipient), please contact the sender by reply e-mail and delete all copies of this message.

Re: ivy integration with automated build tools

[Stephane Bailliez <sb...@gmail.com>]

Shawn Castrianni wrote:
> I have my standalone ivy builds working great such that any developer can build and retrieve dependencies.  However, now I am trying to get automated builds going for continuous integration, scheduled nightly builds, etc.  I was curious what people out there are using.  I always run into the problem of coordinating the automated build systems build numbers and ivy's build numbers.  It would be great if they could be the same such that a developer could look at the automated build website and see builds with numbers that match the number in the ivy repository.
>   

I would not use the 'automated' build number, but do the promotion 'on 
demand'.

Strictly speaking only a human can know if a version is actually a minor 
or a major bump for a version and as far as the 'build number' goes, you 
always have one available which is more meaningful than anything else, 
it's the revision number of your scm which you can pull easily during 
your build process, you don't need to increment/commit etc...your scm 
does that.

> I also see overlap in functionality between ivy and automated build systems with dependency management, publishing, and promotion.  I have all of that working with ivy and am wondering if I just ignore those aspects of the automated build system in favor of ivy?
>   
That depends what you want to do.

In a previous shop (which was actually last century), I was always 
building the current trunk (which were always having fixed revision for 
dependencies), plus the stable branches (with fixed revision of 
dependencies as well of course) plus the 'future possible trunk', which 
was the trunk of all projects all depending on the trunk of their 
dependencies.

The 'future possible trunk' was merely an indication of a possible API 
breakage that could eventually occur if people are releasing a new 
version. So for a  project that has modules which are pretty 'unstable' 
and that has a lot of API changes, etc... it's something that can be 
broken quite often but it can be a useful indicator 'sometimes' if used 
right as if there is relatively good discipline in your organization 
that can allow you to catch mistakes more early than after a release.

In our current shop...we work only with fixed revision. It was 
_extremely_ difficult to move from the original view of 'I depend on  
latest.development of everything' (which grew up organically from the 
fact that the project was created from scratch, modules were created, 
etc... and no real discipline as 'doing thing' was more important than 
'doing it reasonably right').

Depending on the latest.dev for all your modules is as you can imagine 
is a total nightmare in term of stability of component because you never 
know on what you depend and that forces each developer to build the 
entire universe which is utterly stupid and then you have people hacking 
around to actually trying to decrease the build time, which creates even 
more problem, etc.... It's a very good way to have chaos in your 
organization as the view of the world will vary depending on people...

When you work with fixed revision that puts more emphasis on your 
process and you have a reasonably good idea of the code you depend on 
and you can see what people are doing.

-- stephane

Re: ivy integration with automated build tools

[Nicolas Lalevée <ni...@anyware-tech.com>]

Le 15 févr. 08 à 18:09, Shawn Castrianni a écrit :

> I have my standalone ivy builds working great such that any  
> developer can build and retrieve dependencies.  However, now I am  
> trying to get automated builds going for continuous integration,  
> scheduled nightly builds, etc.  I was curious what people out there  
> are using.  I always run into the problem of coordinating the  
> automated build systems build numbers and ivy's build numbers.  It  
> would be great if they could be the same such that a developer could  
> look at the automated build website and see builds with numbers that  
> match the number in the ivy repository.
>
> I also see overlap in functionality between ivy and automated build  
> systems with dependency management, publishing, and promotion.  I  
> have all of that working with ivy and am wondering if I just ignore  
> those aspects of the automated build system in favor of ivy?

I think these are two different things. It seems that you are using  
mainly Ivy for your build system. Then there is a continuous  
integration app which will check developer's work, check the  
integration between the developers. So in fact the continuous  
integration app should run the build system as it is expected to run,  
so with Ivy, so I would say that the app should use Ivy to manage  
dependencies.
But continuous integration app generally doesn't have Ivy support, so  
you will have to translate the Ivy dependencies declaration into the  
CI app configuration.

I know that Cruise Control has some xml configuration, so you would be  
able to generate cruise control settings from ivy.xml via some XSL.  
Same for Hudson, it use XML configuration files. Even more with Hudson  
I have tried to make an Ivy plugin for Hudson [1]. Unfortunately the  
company I work for was not interested in using Hudson, so I didn't get  
the time to properly finish it.

And finally about the build number pushed into the artifact name, I  
know Hudson to have a external HTTP API. See for instance:
http://hudson.ramfelt.se/job/Hudson/org.jvnet.hudson.main$hudson-core/lastBuild/buildNumber 
. Not exactly what you are asking for, but you could probably try  
something.

Nicolas

[1] http://fisheye5.cenqua.com/browse/hudson/hudson/plugins/ivy

Re: ivy integration with automated build tools

[Matthias Kilian <ki...@outback.escape.de>]

On Fri, Feb 15, 2008 at 11:09:03AM -0600, Shawn Castrianni wrote:
> I have my standalone ivy builds working great such that any
> developer can build and retrieve dependencies.  However, now I
> am trying to get automated builds going for continuous integration,
> scheduled nightly builds, etc.  I was curious what people out
> there are using.  I always run into the problem of coordinating
> the automated build systems build numbers and ivy's build numbers.
> It would be great if they could be the same such that a developer
> could look at the automated build website and see builds with
> numbers that match the number in the ivy repository.

We don't use build numbers from the CI tool at all, we just do
automated releases on demand. Here's an overview:

http://www.dead-parrot.de/ivy/

> I also see overlap in functionality between ivy and automated
> build systems with dependency management, publishing, and promotion.
> I have all of that working with ivy and am wondering if I just
> ignore those aspects of the automated build system in favor of
> ivy?

I'd go for the latter. Ivy does a much better job on publishing
(and of course dependency management) then something like Cruisecontrol.

Ciao,
	Kili