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 <mgit...@gmail.com> wrote: > Answers inline prefaced with MG: > > On Tue, Jun 19, 2012 at 3:48 PM, Joel Dice <joel.d...@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. > > >> >>
