On Sun, Aug 6, 2017 at 8:30 PM, Andrew Lau <and...@andrewklau.com> wrote:
>
>
> On Mon, 7 Aug 2017 at 09:11 Ben Parees <bpar...@redhat.com> wrote:
>
>> On Sun, Aug 6, 2017 at 4:42 AM, Andrew Lau <and...@andrewklau.com> wrote:
>>
>>>
>>> On Fri, 28 Jul 2017 at 01:11 Ben Parees <bpar...@redhat.com> wrote:
>>>
>>>> On Thu, Jul 27, 2017 at 9:23 AM, Andrew Lau <and...@andrewklau.com>
>>>> wrote:
>>>>
>>>>> On Thu, 27 Jul 2017 at 22:52 Ben Parees <bpar...@redhat.com> wrote:
>>>>>
>>>>>> On Thu, Jul 27, 2017 at 1:41 AM, Andrew Lau <and...@andrewklau.com>
>>>>>> 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.
>
> 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
>>>>>>> users@lists.openshift.redhat.com
>>>>>>> http://lists.openshift.redhat.com/openshiftmm/listinfo/users
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Ben Parees | OpenShift
>>>>>>
>>>>>>
>>>>
>>>>
>>>> --
>>>> Ben Parees | OpenShift
>>>>
>>>>
>>
>>
>> --
>> Ben Parees | OpenShift
>>
>>
--
Ben Parees | OpenShift
_______________________________________________
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users
