Am 25.10.2011 um 07:09 schrieb Benjamin: > You can put your config in another repo and add the listener on this repo > changes > > > Maybe the simplest :) > 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.
my 2,5 cents Norbert > > Ben > > On Oct 24, 2011, at 6:04 PM, Camillo Bruni wrote: > >> Can't you make it dependent on the configuration? >> Like that you would only fire a build after the configuration was pushed, >> which, hopefully, refers to packages that actually exist :) >> >> cami >> >> On 2011-10-24, at 13:15, Igor Stasenko wrote: >> >>> On 24 October 2011 11:23, Mariano Martinez Peck <[email protected]> >>> wrote: >>>> Marcus, the problem is that jenkis is working VERY well ;) Now, really, >>>> the thing is that I have a lot of packages, and when I change in several of >>>> them, when I commit the first package, Jenkis automatically fires up a >>>> build. That happens even before I can commit the rest of the packages. >>>> Hence...the build become unstabe, and just in the next build it becomes >>>> stable again... >>>> So...I was wondering, maybe we can put kind of delay ? so that Jenkis does >>>> not trigger a build immediatly, but say, after 5 minutes? (that gives me >>>> time to commit all packages) >>>> >>> >>> The solution is simple, as to me: >>> Do not commit the first, before you commit the rest :) >>> >>> Apparently, if jenkins watching for changes in PackageA, which depends >>> on PackageB, >>> first you should commit B, and only then A. >>> >>>> Thanks >>>> >>>> -- >>>> Mariano >>>> http://marianopeck.wordpress.com >>>> >>>> >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >> >> > >
