[users at bb.net] 2 checkout steps in the same builder
Francesco Di Mizio
francescodimizio at gmail.com
Thu Nov 19 15:55:44 UTC 2015
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/db88d4f8/attachment.html>
More information about the users
mailing list