Hi there

Reading the online manual, I came across a line on “Managing dependencies” that I would like elaboration on…

“When the defined stage completes, the pipeline will start. Note that the new pipeline will not be based on the original pipeline changeset.”

Does this mean if a pipeline kicks off another, and (say) they’re both working on the same overall task, there’s no guarantee that the 2nd pipeline will use the same changeset as the original?

So, if, for example, I have a pipeline set up to compile and test and so on my core libraries, and another pipeline to compile and test an application built on them (of which I may have several), and while the first integration is happening in the first pipeline, I commit some more code to Core – does that mean the application-on-top’s pipeline is going to integrate based on the most up-to-date Core libraries it pulls out of source-control? As in, the 1st pipeline doesn’t tell it that “hey, I just built Core@r34523, go build App & test it based on that Core revision”?

I haven’t used Cruise in practise, yet, but that seems as though it would be a problem…?

Is Cruise capable of repeatable builds? (I realise, that’s a separate question). One of the problems we had with un-absolute-revision svn:externals was that either we had a management overhead of remembering to change the revision an external pulls from each time the external is changed (we had many; this turned out to be too crippling, though we’re fixing this in new projects), or we simply let each external pull from HEAD, and sacrifice build-repeatability (we’re using CruiseControl.NET, and we haven’t written something that writes down the revision that each external is at each time a build happens). Can Cruise (or, will Cruise ;-) ) do that for us?

Regards
Pete

Hey Pete

Re: pipeline dependencies, you’re right—for 1.0 we did the simplest possible implementation of dependency modelling, which is just that one pipeline triggers another. Part of the reason we did this is to find out the use cases that people wanted to support, so thanks for your data point. We know the current implementation is naive and we’ll be working to improve it in the future.

Re: repeatable builds—in a way it’s the same question in the sense that it’s all part of your dependency management strategy. Again, we’ll look at supporting your use case.

Our next step in terms of dependency management will probably be to have Cruise’s artifacts repository do it for you. So to take your first use case, the first pipeline would produce some binaries that got uploaded to the artifacts repository. Then when the downstream pipelines were triggered, Cruise would note the label of the upstream pipelines that caused the trigger and either make these labels available as environment variables on the agent so you could pull out the relevant version of the upstream binary from the artifact repository, or provide some declarative mechanism in the Cruise config to pull the artifact out for you automatically on the agent. Later on we’ll look at integrating with tools like Ivy and svn:externals

Hi Jez – cool, that sounds eminently sensible!

(What’s Ivy?)

Ivy is a dependencies manager used on Java projects to deal with large numbers of 3rd party jars.

http://ant.apache.org/ivy/