On Mon, 7 Aug 2017 at 13:40 Ben Parees <[email protected]> wrote: > On Sun, Aug 6, 2017 at 8:30 PM, Andrew Lau <[email protected]> wrote: > >> >> >> On Mon, 7 Aug 2017 at 09:11 Ben Parees <[email protected]> wrote: >> >>> On Sun, Aug 6, 2017 at 4:42 AM, Andrew Lau <[email protected]> >>> wrote: >>> >>>> >>>> On Fri, 28 Jul 2017 at 01:11 Ben Parees <[email protected]> wrote: >>>> >>>>> On Thu, Jul 27, 2017 at 9:23 AM, Andrew Lau <[email protected]> >>>>> wrote: >>>>> >>>>>> On Thu, 27 Jul 2017 at 22:52 Ben Parees <[email protected]> wrote: >>>>>> >>>>>>> On Thu, Jul 27, 2017 at 1:41 AM, Andrew Lau <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> What is the purpose of the {name} URL parameter for the instantiate >>>>>>>> in BuildRequests? ie. >>>>>>>> POST /oapi/v1/namespaces/{namespace}/buildconfigs/{name}/instantiate >>>>>>>> >>>>>>> >>>>>>> the {name} parameter is the name of the buildconfig you are >>>>>>> instantiating a new build of, not the name of the build being created. >>>>>>> >>>>>>> >>>>>> I don't think that's the case. >>>>>> >>>>>> In my example I have the build config "test" >>>>>> >>>>>> So when I POST >>>>>> /oapi/v1/namespaces/{namespace}/buildconfigs/test/instantiate with the >>>>>> body: >>>>>> >>>>>> { >>>>>> "triggeredBy" : {} >>>>>> } >>>>>> >>>>>> It will return the 403 error: >>>>>> >>>>>> "message": "buildconfigs "Unknown" is forbidden: resource name may >>>>>> not be empty" >>>>>> >>>>>> Then if I post something like: >>>>>> >>>>>> { >>>>>> "metadata": { >>>>>> "name": "test2" >>>>>> }, >>>>>> "triggeredBy" : {} >>>>>> } >>>>>> >>>>>> I still get the error: >>>>>> >>>>>> "message": "buildconfigs "test2" is forbidden: buildconfigs "test2" >>>>>> not found", >>>>>> >>>>>> Only until metadata.name matches the buildconfig will I get the 201 >>>>>> created code. >>>>>> >>>>>> Now the second confusing thing is I can POST >>>>>> /oapi/v1/namespaces/{namespace}/buildconfigs/idontexist/instantiate >>>>>> >>>>>> { >>>>>> "metadata": { >>>>>> "name": "test" >>>>>> }, >>>>>> "triggeredBy" : {} >>>>>> } >>>>>> >>>>>> Now this is accepted and creates the build for test, even though I >>>>>> posted to the buildconfig"idontexist" which also doesn't exist.. >>>>>> >>>>> >>>>> you're correct, the rest endpoint for instantiate does not actually >>>>> care what resource you invoked it with, all that matters is the name field >>>>> of the buidlrequest object, the name field provides the name of the >>>>> buildconfig you are instantiating. >>>>> >>>>> >>>>> >>>> >>>> Confusing! >>>> >>>> Is there a better way for overwriting the git reference of the build >>>> request? >>>> >>>> { >>>> "kind": "BuildRequest", >>>> "apiVersion": "v1", >>>> "metadata": { >>>> "name": "test", >>>> "creationTimestamp": null >>>> }, >>>> "revision": { >>>> "type": "Source", >>>> "git": { >>>> "commit": "develop" >>>> } >>>> }, >>>> "triggeredBy": [{ >>>> "message": "Manually triggered" >>>> }] >>>> } >>>> >>>> This will tell the build to pull from the "develop" branch but then the >>>> builds revision section will end up with "Source: develop authored by" >>>> >>> >>> Can you provide me an exact paste of what you're referring to? I'm >>> guessing the issue is we treat the value in "commit" as if it's a commit >>> when describing it, even though in your case it's actually a branch ref. >>> >>> >> It looks like it is because I am putting in the git "reference" as I want >> to deploy the "develop" branch. In the BuildRequest it is called "commit". >> This being my json: >> > > Yes some invalid assumptions/short-sighted choices were made when naming > the api. The reality is that any of the fields labeled "commit" can really > be populated with any valid git reference. > > > >> >> { >> "kind": "BuildRequest", >> "apiVersion": "v1", >> "metadata": { >> "name": "test", >> "creationTimestamp": null >> }, >> "revision": { >> "type": "Source", >> "git": { >> "commit": "develop" >> } >> }, >> "triggeredBy": [{ >> "message": "Manually triggered" >> }] >> } >> >> It ends up pre-filling the resultant "Build" spec with: >> >> [...] >> revision: >> git: >> author: {} >> commit: develop >> committer: {} >> type: Git >> >> It does end up pulling the "develop" branch though. So my "revision" >> input from the BuildRequest overwrites the "Build" spec rather then the >> default when it was automatically pre-filled based on the source. >> > > right, the "revision" field of the build spec was intended as a way to > override the branch that might be provided as part of the gitsource field > and the assumption was that if you were doing so, you'd be doing so with a > commit ("i want to build this exact commit, not the head of the branch"), > but it will work (confusion aside) if what you provide is not actually a > commit. Again, the api is imperfect in several ways, though functional for > the intended purpose. > > This confusion is on our list of things to clean up when we get to a v2 > build api. > > Thanks, this all is working and it did eventually make sense.
> > >> >> Perhaps this is intended as it is possible to put in also specify the >> author and committer values in the BuildRequest? >> >> >>> >>> >>>> >>>> >>>> >>>>> >>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> https://docs.openshift.org/latest/rest_api/openshift_v1.html#create-instantiate-of-a-buildrequest >>>>>>>> >>>>>>>> The docs seem to suggest it's the name but I can set it to anything >>>>>>>> and the name ends up getting pulled from the JSON body ie.: >>>>>>>> >>>>>>>> { >>>>>>>> "metadata": { >>>>>>>> "name": "test" >>>>>>>> }, >>>>>>>> "triggeredBy" : {} >>>>>>>> } >>>>>>>> >>>>>>>> If my JSON body does not include a name then it complains that >>>>>>>> there is no "name". >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> users mailing list >>>>>>>> [email protected] >>>>>>>> http://lists.openshift.redhat.com/openshiftmm/listinfo/users >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Ben Parees | OpenShift >>>>>>> >>>>>>> >>>>> >>>>> >>>>> -- >>>>> Ben Parees | OpenShift >>>>> >>>>> >>> >>> >>> -- >>> Ben Parees | OpenShift >>> >>> > > > -- > Ben Parees | OpenShift > >
_______________________________________________ users mailing list [email protected] http://lists.openshift.redhat.com/openshiftmm/listinfo/users
