ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mitch Gitman <>
Subject Re: Efficient dependency rebuilds for development and debugging
Date Tue, 19 Jun 2012 23:19:39 GMT
Answers inline prefaced with MG:

On Tue, Jun 19, 2012 at 3:48 PM, Joel Dice <> 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.


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