[users at bb.net] Triggered builds getting skipped

Pierre Tardy tardyp at gmail.com
Mon Apr 18 12:30:55 UTC 2016

Please have a look at this PR, which is trying to clarify the build request

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 <tardyp at gmail.com> a écrit :

> Glad this worked!
> Le lun. 18 avr. 2016 12:42, Ed Singleton <singletoned at gmail.com> 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 <tardyp at gmail.com> 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 <singletoned at gmail.com> a
>>> écrit :
>>>> On Thu, Apr 14, 2016 at 8:19 PM, Pierre Tardy <tardyp at gmail.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.buildbot.net/pipermail/users/attachments/20160418/050c8f2f/attachment.html>

More information about the users mailing list