[Pharo-project] Jenkis small delay possible?
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) Thanks -- Mariano http://marianopeck.wordpress.com
On 24 October 2011 11:23, Mariano Martinez Peck <marianopeck@gmail.com> 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.
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 <marianopeck@gmail.com> 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.
On 24/10/11 12: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 :)
If the configuration you want to build is the baseline (i.e. the latest package versions), then there will always be a time window where the set of packages would be inconsistent. I suppose you could trigger a build based on the configuration, but in the case of the baseline you would just "touch" the configuration (i.e. commit, but no actual change) - a "poor man's" atomic commit.
You can put your config in another repo and add the listener on this repo changes Maybe the simplest :) 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 <marianopeck@gmail.com> 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.
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 <marianopeck@gmail.com> 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.
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.
participants (6)
-
Benjamin -
Camillo Bruni -
Igor Stasenko -
Mariano Martinez Peck -
Norbert Hartl -
Yanni Chiu