Mailing-List: contact ivy-user-help@ant.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ivy-user@ant.apache.org
Received-SPF: pass (athena.apache.org: domain of mgitman@gmail.com designates
 209.85.212.45 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAEJc6MX-dH3oaLkV=_4vBaeMfSyeuVco29F967Wn+7qgzJM+Xg@mail.gmail.com>
References: 
 <CAEJc6MWnAsQe9M4v48Vc4c0D7w_hbvj3rx_HFbjyM3aqJwxnvg@mail.gmail.com>
	<alpine.DEB.2.00.1206191547240.23545@jdpc.ecovate.com>
	<CAEJc6MX-dH3oaLkV=_4vBaeMfSyeuVco29F967Wn+7qgzJM+Xg@mail.gmail.com>
Date: Tue, 19 Jun 2012 17:21:54 -0700
Message-ID: 
 <CAEJc6MWmOYWKztd9b73fJ4Nwz0DfASdSz=fotk9WY=D+hftrBQ@mail.gmail.com>
Subject: Re: Efficient dependency rebuilds for development and debugging
From: Mitch Gitman <mgitman@gmail.com>
To: ivy-user@ant.apache.org
Content-Type: multipart/alternative; boundary=bcaec54eee66e8851a04c2dc6217

--bcaec54eee66e8851a04c2dc6217
Content-Type: text/plain; charset=UTF-8

Quick correction for more precise language, and then I'll leave things be.

I wrote: " You're never going to have Jenkins jobs for B running
simultaneously. Plus, for each build, you're always going to know which
commit on which project manually kicked off each build stream."

I meant: " You're never going to have two or more Jenkins jobs for project
B running simultaneously. Plus, for each build, you're always going to know
which commit on which project automatically kicked off a build stream, or
else you're going to know that it was kicked off  manually."

On Tue, Jun 19, 2012 at 4:19 PM, Mitch Gitman <mgitman@gmail.com> wrote:

> Answers inline prefaced with MG:
>
> On Tue, Jun 19, 2012 at 3:48 PM, Joel Dice <joel.dice@gmail.com> wrote:
>
>> Hi Mitch,
>>
>> Thanks for your response.  Please see my comments below.
>>
>>
>>
>> Yes, that's what happens on the CI server.  Are you suggesting that each
>> developer run a CI server on his or her development machine and let it take
>> care of cascading changes?
>>
>
> MG: No, what I'm suggesting is that, whatever modules a developer is
> actively working on, they publish them to a local Ivy repository. The more
> modules you're actively developing, the more it behooves you to automate a
> multimodule build.
>
>>
>> Also, I don't necessarily want to rebuild every module that depends
>> directly or indirectly on the one I just changed.  Instead, I normally want
>> to rebuild the minimum amount of code needed to test a specific top-level
>> (i.e. most-dependent) project.  Once I'm happy with my change as far as it
>> concerns that project, I can kick off builds of other projects that depend
>> on the module(s) I've changed and run their respective tests, but it make
>> take several iterations of debugging the initial project before I get to
>> that point.
>>
>> MG: If you're actively integrating the changes in your component project
> against some dependent projects but not others, then the latter projects
> should not be depending on integration versions. They should be waiting for
> milestone or release versions to come out. Also, there's something curious
> about the following language: "Once I'm happy with my change as far as it
> concerns that project, I can kick off builds of other projects..." There
> should be no manual steps in the process, at least on the CI server. Once
> you check in changes to one project, you should let them bubble up
> automatically to everything that depends on their integration versions.
> Cascading builds on a CI server is a cost-free exercise, and if something
> is good enough to check in, it's good enough to check about its downstream
> effects. There's always revert.
>
>
>>
>>>
>> I don't think that will give me reentrant builds, though.  If I kick off
>> two builds at around the same time (say the build takes a while and I want
>> to build and test two separate changes in parallel), it's non-deterministic
>> as to what I'll end up with when the most-dependent module is built.
>>
>
> MG: Take the example of Jenkins/Hudson. You're never going to have Jenkins
> jobs for B running simultaneously. Plus, for each build, you're always
> going to know which commit on which project manually kicked off each build
> stream. Plus, you know exactly which version of each project has been built
> and published along with the precise versions of the things it depends on.
>
> All the things you should care about are deterministic. The build you care
> the most about is the latest one. You want to get the latest green. You
> want to keep it green. And if you do see a red, you want to be able to
> reproduce it in some way in case you can't readily explain what went wrong.
>
> It sounds like at this point we're digressing away from the particulars of
> Ivy usage and into a broader discussion of continuous integration
> philosophy, so I'm probably going to have to let this be my last word on
> this mailing list thread.
>
>
>>
>>

--bcaec54eee66e8851a04c2dc6217--