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 < francescodimi...@gmail.com> wrote: > only one buildrequest seems to exist in the db, still Rest says 2 ;) > > buildbot@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@3d9b217df954:~$ > > On Thu, Nov 19, 2015 at 4:55 PM, Francesco Di Mizio < > francescodimi...@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 < >> francescodimi...@gmail.com> wrote: >> >>> the default sqlite back end. >>> >>> On Wed, Nov 18, 2015 at 5:26 PM, Pierre Tardy <tar...@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 < >>>> francescodimi...@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 < >>>>> francescodimi...@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 <tar...@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 < >>>>>>> francescodimi...@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 < >>>>>>>> francescodimi...@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 <tar...@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 < >>>>>>>>>> francescodimi...@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 < >>>>>>>>>>> francescodimi...@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 <tar...@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 < >>>>>>>>>>>>> francescodimi...@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@buildbot.net >>>>>>>>>>>>>> https://lists.buildbot.net/mailman/listinfo/users >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>> >>>>> >>> >> >
_______________________________________________ users mailing list users@buildbot.net https://lists.buildbot.net/mailman/listinfo/users