[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: BuildRequest name parameter





On Mon, 7 Aug 2017 at 13:40 Ben Parees <bparees redhat com> wrote:
On Sun, Aug 6, 2017 at 8:30 PM, Andrew Lau <andrew andrewklau com> wrote:


On Mon, 7 Aug 2017 at 09:11 Ben Parees <bparees redhat com> wrote:
On Sun, Aug 6, 2017 at 4:42 AM, Andrew Lau <andrew andrewklau com> wrote:

On Fri, 28 Jul 2017 at 01:11 Ben Parees <bparees redhat com> wrote:
On Thu, Jul 27, 2017 at 9:23 AM, Andrew Lau <andrew andrewklau com> wrote:
On Thu, 27 Jul 2017 at 22:52 Ben Parees <bparees redhat com> wrote:
On Thu, Jul 27, 2017 at 1:41 AM, Andrew Lau <andrew 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.


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?
 
 

 

 


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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]