[users at bb.net] 2 checkout steps in the same builder
Francesco Di Mizio
francescodimizio at gmail.com
Mon Jan 18 16:16:40 UTC 2016
Now that I've set mail notifier up, I am also getting two emails per build.
Again, Do you want me to file a bug?
Francesco
On Thu, Nov 19, 2015 at 5:28 PM, Francesco Di Mizio <
francescodimizio at gmail.com> wrote:
> 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/20160118/76544476/attachment.html>
More information about the users
mailing list