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