New Build experience via CLI

[gabemontero]

today oc new-app and oc new-build can be pointed at git repositories or local source code (i.e. binary builds) to define build v1 build configs

binary builds are already on the build v2 roadmap, but is that just an operator side / api statement ?

new-app/new-build are somewhat considered "legacy" devtools at this point, but it is unclear if a replacement is truly ready

should buildv2 still integrate with those oc verbs? or is something else ready to pick up the slack?

[sbose78]

I would like to have buildv2 integrate with our oc tooling. The simplicity of oc new-app and oc new-build experience is something we should not lose.

[sbose78]

cc @zhangtbj Were you looking for a similar experience ?

[siamaksade]

It might make sense to bootstrap a new CLI focused on builds v2. This CLI could then become a oc plugin and managed through krew

[zhangtbj]

Hi @sbose78 and @siamaksade ,

Yes, After Release 0.1, we plan to have the local(binary) support in build v2.

I also investigated and summarized the oc binary build in build v1 before:

I think it is a good way.

• But I remember we need provide an additional upload service/controller to support to upload the source code archive file from local to server side.
• And it is better there is an individual CLI (which can be a plugin of oc), so that the build v2 user from community can use it directly with download the full capabilities oc CLI

What do you think? :)

[adambkaplan]

In discussion with @sbose78 @gabemontero @coreydaley-redhat @otaviof and @siamaksade, we think that the CLI should have a similar new-build experience that helps developers create a Build object. The broader new-app functionality is beyond the scope of this project.

[zhangtbj]

It may be also related to the local build support, comment here for a record: https://blogs.vmware.com/opensource/2020/11/17/buildkit-cli-for-kubectl/
(The kubectl plugin can build the Dockerfile locally and run the image on kube without pushing it to container registry)

[zhangtbj]

Hi @gabemontero ,

Thanks for the info, I took a look at the Binary Build proposal in this document: https://docs.google.com/document/d/1wo7-tdssRdEHSGX5D6fCbJXEs7ghawRnQOq1WgaSUUA

If I understand you correctly, you prefer to use https://github.com/rhuss/buildah-poc as PoC for build v2, is that correct?

We also did some investigation before and had a try the buildah-poc, I think kubectl cp performance maybe is not good: #97 (comment)

So I am wondering:

• Can we use another sync way (like ksync: https://github.com/ksync/ksync) to sync or upload the binary from client to server side better, or leverage OpenShift BuildConfig Binary-Builds in build v1, to have a similar upload service or a REST API in our build v2 side to help receive and get binary from local?
• Can we use the Tekton condition (https://github.com/tektoncd/pipeline/blob/master/docs/conditions.md) to check if the binary is uploaded to server side correctly
• For the upload service, I think we also need to consider, do you need one build service or pod to receive the bianry and do the build for each buildrun, or do we want to use a central upload service as a kube service to serve the upload request for all buildruns.

Above are just my thinking, we can think about or discuss later together.

[gabemontero]

Hi @gabemontero ,

Thanks for the info, I took a look at the Binary Build proposal in this document: https://docs.google.com/document/d/1wo7-tdssRdEHSGX5D6fCbJXEs7ghawRnQOq1WgaSUUA

If I understand you correctly, you prefer to use https://github.com/rhuss/buildah-poc as PoC for build v2, is that correct?

No, I don't necessarily have a preference. That most likely was something from @otaviof at least that is my assumption.

We should definitely iterate on the implementation details. Including what you have below.

My preferences if any revolve more around what NOT to do, namely we should hopefully be able improve upon on how it was done with OpenShift Builds V1, which I provided the details for how it was done in the document. The approach used there stems in part from when it was implemented and what was and was not available in k8s at the time.

We also did some investigation before and had a try the buildah-poc, I think kubectl cp performance maybe is not good: #97 (comment)

So I am wondering:

* Can we use another sync way (like ksync: https://github.com/ksync/ksync) to sync or upload the binary from client to server side better, or leverage `OpenShift BuildConfig Binary-Builds` in build v1, to have a similar upload service or a REST API in our build v2 side to help receive and get binary from local?

* Can we use the Tekton condition (https://github.com/tektoncd/pipeline/blob/master/docs/conditions.md) to check if the binary is uploaded to server side correctly

* For the upload service, I think we also need to consider, do you need one build service or pod to receive the bianry and do the build for each buildrun, or do we want to use a central upload service as a kube service to serve the upload request for all buildruns.

Above are just my thinking, we can think about or discuss later together.

[gabemontero]

So since I opened this a year and a half ago, some things have changed:

• https://github.com/shipwright-io/cli now exists
• it already some analogous capabilities wrt pointing it to source repos ... see https://github.com/shipwright-io/cli/blob/e3e829781fe4195511ed737bbbb1ded8b20fedce/pkg/shp/cmd/build/create.go#L27
• local build based dev is in progress under other github issues
  -- see Local source code feature (using bundle images) cli#35 from @HeavyWombat
  -- see SHIP-0021: Local Source Upload community#11 and the prototypes demoed there by @otaviof

Hence, I think this umbrella item I opened way back when is past its usefulness.

Any remaining items in my opinion in mapping oc new-build / new-app capabilities I at least are dependent on analogous imagestream support i.e. shipwright-io/community#25 from @imjasonh based on @ricardomaraschini grass root efforts, where we "pick" the builder / base image based on source code analysis of the remote/local repo being used. CLI items would in theory stem from that.

So I closing this out