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

Wed Nov 18 15:33:25 UTC 2015

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/a6bd79c4/attachment.html>