[users at bb.net] 2 checkout steps in the same builder

Francesco Di Mizio francescodimizio at gmail.com
Thu Nov 19 16:28:09 UTC 2015


only one buildrequest seems to exist in the db, still Rest says 2 ;)

buildbot at 3d9b217df954:~$ sqlite3 state.sqlite .dump |grep -i insert | grep
buildrequest
INSERT INTO "buildrequests" VALUES(1,1,5,0,0,-1,1447950188,NULL,0);
INSERT INTO "buildrequest_claims" VALUES(1,1,1447950188);
buildbot at 3d9b217df954:~$

On Thu, Nov 19, 2015 at 4:55 PM, Francesco Di Mizio <
francescodimizio at gmail.com> wrote:

> By itself it's not too bad as long as you know it. The moment you make a
> websocket connection and subscribe to events for that buildrequest id
> though, how can one assure he's receiving the right messages? What am I
> even subscribing to?
>
> Do you want me to file a bug?
>
>
>
> On Wed, Nov 18, 2015 at 5:46 PM, Francesco Di Mizio <
> francescodimizio at gmail.com> wrote:
>
>> the default sqlite back end.
>>
>> On Wed, Nov 18, 2015 at 5:26 PM, Pierre Tardy <tardyp at gmail.com> wrote:
>>
>>> Which db back end are you using? Normally there is unique key constraint
>>> on buildrequestid.
>>>
>>> Le mer. 18 nov. 2015 16:35, Francesco Di Mizio <
>>> francescodimizio at gmail.com> a écrit :
>>>
>>>> Ps: managed to confirm that's only happening when passing in multiple
>>>> sourcestamps.
>>>>
>>>> Not sure if this is relevant but my master is set to never collapse
>>>> anything.
>>>>
>>>> On Wed, Nov 18, 2015 at 4:33 PM, Francesco Di Mizio <
>>>> francescodimizio at gmail.com> wrote:
>>>>
>>>>> Hey Pierre,
>>>>>
>>>>> There you go:
>>>>>
>>>>> {
>>>>>
>>>>>   "buildrequests": [
>>>>>     {
>>>>>       "builderid": 4,
>>>>>       "buildrequestid": 1,
>>>>>       "buildsetid": 1,
>>>>>       "claimed": true,
>>>>>       "claimed_at": 1447860725,
>>>>>       "claimed_by_masterid": 1,
>>>>>       "complete": true,
>>>>>       "complete_at": 1447860727,
>>>>>       "priority": 0,
>>>>>       "results": 2,
>>>>>       "submitted_at": 1447860725,
>>>>>       "waited_for": false
>>>>>     },
>>>>>     {
>>>>>       "builderid": 4,
>>>>>       "buildrequestid": 1,
>>>>>       "buildsetid": 1,
>>>>>       "claimed": true,
>>>>>       "claimed_at": 1447860725,
>>>>>       "claimed_by_masterid": 1,
>>>>>       "complete": true,
>>>>>       "complete_at": 1447860727,
>>>>>       "priority": 0,
>>>>>       "results": 2,
>>>>>       "submitted_at": 1447860725,
>>>>>       "waited_for": false
>>>>>     }
>>>>>   ],
>>>>>   "meta": {
>>>>>     "total": 2
>>>>>   }
>>>>> }
>>>>>
>>>>>
>>>>> On Wed, Nov 18, 2015 at 1:55 PM, Pierre Tardy <tardyp at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> It looks indeed very weird that the rest api returns 2 times the
>>>>>> exact same buildrequest
>>>>>> Normally (unless there is a bug), we keep the track of the original
>>>>>> buildrequest so that one entity wanting to know what's up with it can know
>>>>>> which buildrequest know what's up with it even if there is collapsing.
>>>>>>
>>>>>> I would like to see the return of rest api without field filtering:
>>>>>>
>>>>>> api/v2/buildrequests?buildsetid=1
>>>>>>
>>>>>> Le mar. 17 nov. 2015 à 20:02, Francesco Di Mizio <
>>>>>> francescodimizio at gmail.com> a écrit :
>>>>>>
>>>>>>> Came across a bit of an issue.
>>>>>>>
>>>>>>> Is it possible that wehn calling addBuildsetForSourceStamps with 2
>>>>>>> sourcestamps, buildbot will create 2 buildrequests and then only collapse
>>>>>>> them when one of the 2 kicks in?
>>>>>>> Those 2 buildrequests in fact show up as 2 distinct ones in the web
>>>>>>> ui until the build starts. When it does one will remain.
>>>>>>>
>>>>>>> However they still seem to exist after being collapsed
>>>>>>>
>>>>>>>
>>>>>>> api/v2/buildrequests?buildsetid=1&field=buildrequestid&field=claimed_at&field=builderid&field=buildsetid
>>>>>>>
>>>>>>> returns 2 identical buildrequests
>>>>>>>
>>>>>>>   "buildrequests": [
>>>>>>>     {
>>>>>>>       "builderid": 3,
>>>>>>>       "buildrequestid": 1,
>>>>>>>       "buildsetid": 1,
>>>>>>>       "claimed_at": 1447786507
>>>>>>>     },
>>>>>>>     {
>>>>>>>       "builderid": 3,
>>>>>>>       "buildrequestid": 1,
>>>>>>>       "buildsetid": 1,
>>>>>>>       "claimed_at": 1447786507
>>>>>>>     }
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Nov 17, 2015 at 12:30 PM, Francesco Di Mizio <
>>>>>>> francescodimizio at gmail.com> wrote:
>>>>>>>
>>>>>>>> it indeed worked very well. It was not clear to me that in the
>>>>>>>> source step I was allowed to pass in the code base I want the step to deal
>>>>>>>> with!
>>>>>>>>
>>>>>>>> Much appreciated
>>>>>>>>
>>>>>>>> Francesco
>>>>>>>>
>>>>>>>> On Tue, Nov 17, 2015 at 12:26 AM, Pierre Tardy <tardyp at gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Yes, this is a very common use case that should fall upon the the
>>>>>>>>> codebase principle. You should really try and use codebase.
>>>>>>>>>
>>>>>>>>> Le lun. 16 nov. 2015 à 23:51, Francesco Di Mizio <
>>>>>>>>> francescodimizio at gmail.com> a écrit :
>>>>>>>>>
>>>>>>>>>> To clarify a bit more. The code coming from git is not part of
>>>>>>>>>> the final product. The product infact does not depend at all on the code in
>>>>>>>>>> Git. Git only contains code to help build what comes from p4. Also Github
>>>>>>>>>> will never produce by itself a change to be built, those chances will only
>>>>>>>>>> come from perforce.
>>>>>>>>>>
>>>>>>>>>> On Mon, Nov 16, 2015 at 11:29 PM, Francesco Di Mizio <
>>>>>>>>>> francescodimizio at gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hey Pierre,
>>>>>>>>>>>
>>>>>>>>>>> in my case there's no change triggering the build. Or better all
>>>>>>>>>>> I have is a web app kicking a cutom scheduler in turn calling
>>>>>>>>>>> addBuildsetForSourceStamps
>>>>>>>>>>> Right now I am using a single Sourcestamp with an empty string
>>>>>>>>>>> named codebase to feed addBuildsetForSourceStamps
>>>>>>>>>>> Should I just pass two SourceStamps in to
>>>>>>>>>>> addBuildsetForSourceStamps?
>>>>>>>>>>>
>>>>>>>>>>> I am not sure if that's what I need. Ideally if a build fails
>>>>>>>>>>> and I want to re-build the same thing, I'd like Git to always get latest.
>>>>>>>>>>> Hope it's a bit more clear now.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>>  Francesco
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Mon, Nov 16, 2015 at 9:08 PM, Pierre Tardy <tardyp at gmail.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi Francesco,
>>>>>>>>>>>>
>>>>>>>>>>>> You need to specify two different codebases for your two git
>>>>>>>>>>>> steps.
>>>>>>>>>>>> The source steps are overriding the branch arguments if there
>>>>>>>>>>>> is a change triggering the build. changes are associated to codebase, and
>>>>>>>>>>>> will only work for the corresponding source steps.
>>>>>>>>>>>>
>>>>>>>>>>>> Regards
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Le lun. 16 nov. 2015 à 19:34, Francesco Di Mizio <
>>>>>>>>>>>> francescodimizio at gmail.com> a écrit :
>>>>>>>>>>>>
>>>>>>>>>>>>> Hello guys,
>>>>>>>>>>>>>
>>>>>>>>>>>>> my main checkout step is a p4 step. This is the repo that's
>>>>>>>>>>>>> got stuff I am interested into having compiling and tested.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> My build scripts are coming from github. When I add a git step
>>>>>>>>>>>>> to check them out, Git step will no matter what use the branch property.
>>>>>>>>>>>>> Such a property (say 'main') only makes sense for the p4 step. I need to
>>>>>>>>>>>>> use an other property for the git step (like 'master') .
>>>>>>>>>>>>>
>>>>>>>>>>>>> Docs say
>>>>>>>>>>>>>
>>>>>>>>>>>>> @param branch: The branch or tag to check out by default. If
>>>>>>>>>>>>> a build specifies a different branch, it will
>>>>>>>>>>>>> be used instead of this.
>>>>>>>>>>>>>
>>>>>>>>>>>>> So no matter what I pass to the step as branch, it'll still
>>>>>>>>>>>>> use the branch property. Any idea how to work this around? Basically I dont
>>>>>>>>>>>>> have to build a CI system around the git repo, ideally I'd just like to
>>>>>>>>>>>>> blindly check out its branches.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On a side note: is that way renderables beheave (just like
>>>>>>>>>>>>> 'branch' is a renderable for Git step)
>>>>>>>>>>>>>
>>>>>>>>>>>>> Many thanks,
>>>>>>>>>>>>>  Frank
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> users mailing list
>>>>>>>>>>>>> users at buildbot.net
>>>>>>>>>>>>> https://lists.buildbot.net/mailman/listinfo/users
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.buildbot.net/pipermail/users/attachments/20151119/9fe45ce0/attachment.html>


More information about the users mailing list