Community
Participate
Working Groups
This is a continuation of bug 489789. It would be best to "automate" the switch from I-builds to N-builds and back. I think of two solutions: A. We could have a job that changed a number of things based on the "phase" of development. That is a "little off" in some cases, since, for example, once the milestone is declared, we do not immediately switch back to the N-builds. We have to wait until there IS a valid N-build. B. Another thought, a bit radical maybe, we could "switch" every time we promoted an N repo or an I repo. This would, for example, do a short-term switch to the I build from about noon on Tuesday to about midnight on Tuesday. Technically "more accurate" but might be harder to explain. :) Especially since sometimes we have to do a second I-build some weeks.
> B. Another thought, a bit radical maybe, we could "switch" every time we > promoted an N repo or an I repo. I like that one. AFAIK, builds with compile errors do not get promoted, so this could also help in situations where the N-build on Monday evening failed, and the error was fixed in the I-build on Tuesday.
(In reply to Markus Keller from comment #1) > > B. Another thought, a bit radical maybe, we could "switch" every time we > > promoted an N repo or an I repo. > > I like that one. AFAIK, builds with compile errors do not get promoted, so > this could also help in situations where the N-build on Monday evening > failed, and the error was fixed in the I-build on Tuesday. You are correct. If there is a "build failure" of any sort (compile errors, "time outs", etc.) The repository is not "promoted". I like this idea too, especially if we can make it switch to the specific (simple) repo that was just built since that will be a little faster than reading "the whole composite". One potential problem, though, is if jobs are relying on the repository in ${HOME}/.m2/repository then the repository might "switch" in the middle of their job. I am not sure how small or large the window of opportunity for errors would be. To minimize that sort of error, it would be best to use "private local repository" -- which I have always recommended that people use (as well as "use private tmp directory") but do not know how many do. And, of course, if they do that and also "clean" their entire workspace before each build, then that will make their jobs a little longer. The 'ol "speed" vs. "correctness" trade-off. But, sticky with my philosophy that "the more committers learn about Hudson the better", I would still be inclinced to make this sort of automation improvement, even if might cause issues depending on how jobs were set-up.
(In reply to Markus Keller from comment #1) > > B. Another thought, a bit radical maybe, we could "switch" every time we > > promoted an N repo or an I repo. > > I like that one. +1 too.
