Please have a look at this PR, which is trying to clarify the build request collapser. https://github.com/buildbot/buildbot/pull/2128
I agree that we should default to False, and I will bring up the topic in the next weekly meeting for a decision. Le lun. 18 avr. 2016 à 12:45, Pierre Tardy <[email protected]> a écrit : > Glad this worked! > > Le lun. 18 avr. 2016 12:42, Ed Singleton <[email protected]> a écrit : > >> Setting collapseRequests=False globally appears to have fixed the >> problem. From reading the documentation, I can see why that might have >> been a problem for us, as we are creating multiple builds with all the same >> details (even the same revision of code) but with a slightly different >> property for each one. I still can't see why it would be so intermittent >> though. The number of them that were collapsed seemed quite random. >> >> I would suggest that False should be the default for this setting as it >> only appears to be a performance enhancement. I'd also suggest that it >> should check whether the properties of the builds are the same before >> collapsing them. >> >> Thanks for all your help with this. >> >> Ed >> >> On Fri, Apr 15, 2016 at 12:30 PM, Pierre Tardy <[email protected]> wrote: >> >>> Interrestingly, I see a lot of buildrequests that are indeed claimed, >>> complete and with "SKIPPED" (code 6) results. >>> They are finished 7 seconds after being claimed. >>> That would be interresting to also see the list of builds, to see if >>> there is a corresponding SKIPPED build. >>> >>> I did a quick search for SKIPPED in the source code, and see that a >>> buildrequests can be marked SKIPPED by the build request collapser: >>> >>> # Before adding new buildset/buildrequests, we must examine each >>> unclaimed >>> # buildrequest. >>> # EG: >>> # 1. get the list of all unclaimed buildrequests: >>> # - We must exclude all buildsets which have at least 1 claimed >>> buildrequest >>> # 2. For each unclaimed buildrequests, if compatible with the new >>> request >>> # (sourcestamps match, except for revision) Then: >>> # 2.1. claim it >>> # 2.2. complete it with result SKIPPED >>> >>> This can explain that the more you have, and the more it skips. >>> >>> You may want to force collapseRequests=False in your triggered builder >>> configuration. >>> >>> >>> Le ven. 15 avr. 2016 à 13:16, Ed Singleton <[email protected]> a >>> écrit : >>> >>>> On Thu, Apr 14, 2016 at 8:19 PM, Pierre Tardy <[email protected]> wrote: >>>>> >>>>> >>>>> I would suggest to upgrade to beta8 >>>>> >>>> >>>> I have done, and I still have the same problem. >>>> >>>> If the problem persists, I would suggest to create a trac, and append >>>>> the result of the rest api like >>>>> >>>>> /api/v2/buildrequests?limit=50 >>>>> This will tell the list of pending buildrequests, to see if there are >>>>> claimed or not. >>>>> We can then have the evidence if the problem comes in the buildrequest >>>>> distributor, or in the build subsystem. >>>>> >>>> >>>> Unfortunately I can't register with Trac at the moment as it appears >>>> our IP is on a blacklist :-( I'll do that from home over the weekend. >>>> >>>> Another thing I've noticed about the problem is that it is >>>> intermittent. Forcing a build that triggers 6 others, with 12 workers (all >>>> idle), between 3 and 6 of them will actually get built. If I immediately >>>> cancel it, and force it again, within a couple of goes one will work with >>>> all 6. >>>> >>>> I've waited over 30 minutes and they never appear. >>>> >>>> I've attached the results of the api call (I reverse sorted them so >>>> that the latest ones were selected). The last 6 (480-485) were done >>>> together, and 5 worked and 1 didn't. >>>> >>>> This afternoon, I'll try to create a minimal failing example that I can >>>> share. >>>> >>>> Ed >>>> >>> >>
_______________________________________________ users mailing list [email protected] https://lists.buildbot.net/mailman/listinfo/users
