search

shipwright-io / build

Shipwright - a framework for building container images on Kubernetes
https://shipwright.io
Apache License 2.0
657 stars 112 forks source link

New Build experience via CLI #59

Closed gabemontero closed 3 years ago

gabemontero commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

cc @zhangtbj Were you looking for a similar experience ?

siamaksade commented 4 years ago

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 commented 4 years ago

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: box-image

I think it is a good way.

What do you think? :)

adambkaplan commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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: https://github.com/shipwright-io/build/issues/97#issuecomment-636444531

So I am wondering:

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

gabemontero commented 3 years ago

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 commented 3 years ago

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

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. https://github.com/shipwright-io/community/pull/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