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

Francesco Di Mizio francescodimizio at gmail.com
Wed Nov 18 16:46:52 UTC 2015


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/20151118/192a5098/attachment.html>


More information about the users mailing list