openshift/openshift-restclient-python

No mechanism for starting a build from a BuildConfig

chiefnoah opened this issue · 8 comments

As far as I can tell, there's no way to start a build from a BuildConfig via this module, or at least it's not documented.

I'm not totally sure how triggering a build works, but if it's a subresource on the BuildConfig resource then you can access it from the subresources attribute, ie

build_configs = client.resources.get(api_version='build.openshift.io/v1', kind='BuildConfig')
# This will be a dictionary of `Subresource` objects, which define `get` `update` etc just like the regular `Resource` objects
build_configs.subresources

You are right that the subresource interactions do need more documentation

It may still be possible using the subresources, but even then the process for starting a build via the REST API isn't documented (well?) in OpenShift itself, so even if it's technically possible it requires digging into OpenShift's code to figure out how to do it.

For what it's worth, here's the solution for instantiating a build config which uses s2i to get the source from Git repository.

v1_build_configs = dyn_client.resources.get(api_version="v1", kind="BuildConfig")
v1_buid_configs.subresources["instantiate"].create(
	name=name,
	namespace=namespace,
	body={
		"kind": "BuildRequest",
		"apiVersion": "build.openshift.io/v1",
		"metadata": {
			"name": name,
		},
	},
)

Oddly enough, I'm pretty sure you have to pass the name as metadata with the body despite passing it in as a parameter. I forget.
A dead reference is: docs.okd.io/latest/rest_api/openshift_v1.html#create-instantiate-of-a-buildrequest

Separately, I haven't been able to figure out a solution for instantiating binary builds, however. In particular, for an archive x.tar.gz, passing --from-archive=x.tar.gz works with the oc tool. However, attempting to pass this archive via the Curl seen with --loglevel=999 for the build bears no fruit.

strange, would you mind pasting the requests oc is making?

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

Stale issues rot after 30d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle rotten
/remove-lifecycle stale

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Exclude this issue from closing again by commenting /lifecycle frozen.

/close

@openshift-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Exclude this issue from closing again by commenting /lifecycle frozen.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.