On 25/10/11 3:43 AM, Norbert Hartl wrote:
No, the simplest is to leave it as it is. Do you really think it is worth the effort? A new repo and pseudo configuration commits just to prevent a few bogus "jenkins became unstable" mails? What is the problem with it? If you know that it can happen you can just look at it that way. In this particular case there is not only a broken build but also a new build in the queue. If you just develop the habbit to look after the last build you will see there is no problem. I have plenty of experience how this "clever tweaking" of the configuration management tools has the potential to make it really worse. Even the raise of the delay will get on someones nerves that tries to fix a configuration. That will lead to have to do a lot of builds until it works. For this use case the 5 minutes delay is already unbearable, etc.
I agree - adjust to look for a new build in the queue. But, you have to wait for 2 or 5 minutes (minus build time) before the new build appears.
A long while back, I used to have builds occasionally fail (unexpectedly?). The first two times I dug in, and debugged the test failure to find a code inconsistency. Then I looked at the repository to find that there was a newer version with a very recent timestamp (i.e. a difference of about the time I'd spent debugging). Eventually, I learned that if the build failure was not due to my code, I did not debug it first thing. Instead, I started a new build.
One way to shorten the commit time is to commit to a local repository, then upload to squeaksource. That leaves time to browse changes and think about the commit comments.
