Tekton generation resources

lordofthejars commented 4 years ago

Description

Currently we are offering to generate resources for kubernetes, openshift and knative, why not add Tekton as well as it is a project we support in RH?

Implementation ideas

Adds support in Dekorate for Tekton.

geoand commented 4 years ago

cc @iocanel

iocanel commented 4 years ago

I recently created tekton support in the kubernetes-client and I intend to do the same with dekorate and quarkus.

maxandersen commented 4 years ago

maybe i'm a bit backwards here but tekton should be generated before you build your app as tekton is what drives your build.... is it not more about having tekton-ci.yml example somewhere ? or am i missing something something ?

iocanel commented 4 years ago

I feel that just having a tekton-ci.yml doesn't just cut it. There is not a one size fits all thing that can be treated as a Dockerfile (something that its same for 99% of the users).

Why?

Generated resources refer to git repositories etc (not biggie but...).
Needs RBAC & Auth configuration for pushing to remote registries.
In many cases, persistent volumes are required.
Even the smallest changes span across multiple resources.

So, in my opinion, there is huge value in having a tool that generates those resources. If that tool, is using the same configuration mechanism/philosophy as the kubernetes extension IMHO, makes things much more simple and much more familiar to the user.

BTW, a very early draft of tekton support added in dekorate last week, and here's a quick demo of how it looks like: https://www.youtube.com/watch?v=AVFn0l6aOi4

@maxandersen @lordofthejars ^

maxandersen commented 4 years ago

My concern is less about how its generated but when.

ie. kubernetes yaml gets generated during our build and then used for deployment. makes sense.

but the tekton files are to be present before the build is done ... there is a chicken and egg issue here ;)

also, I was under the high impression that for tekton we wouldn't be pushing the "raw" tekton pipeline definitons but use something more high level as gitlab / github yaml but I could be wrong here.

iocanel commented 4 years ago

ie. kubernetes yaml gets generated during our build and then used for deployment. makes sense.

It really isn't that different. Tekton yaml generated during our build and then used for deployment. The deployed pipeline can be used to trigger other in cluster builds/deployments.

I understand the concern that the in cluster build may generate another Tekton yaml, but IMHO that's not really a problem.

maxandersen commented 4 years ago

@iocanel i'm missing something i'm sure but what I hear you say is that the sequence a user will do with this estup is:

git clone project
cd project
mvn package (generates kubernetes resources and tekton yaml)
mvn deploy (does a tkn / kubectl dance to setup a k8s / tekton based build)
...
tekton is triggered and does:

git clone project
cd project
mvn package (generates kubernetes resources and tekton yaml)
mvn deploy (this time just do what corresponds. to kubectl apply)

What is the value to that versus:

git clone project
cd project
add tekton-ci.yml to project 
git commit/push 
tekton via webhooks notices project cahgned and uses the tekton-ci.yml and then do:
git clone project
cd project
mvn package (generates kubernetes resources)
mvn deploy (this time just do what corresponds. to kubectl apply)

why the meta-generation need instead of just a basic pipeline definition - what am I missing ?

iocanel commented 4 years ago

What I think you are missing is that there is no teketon-ci.yml that you apply and have every thing magically working. You are going to need to add lot of glue(rbac, registries, pv and so on). IMHO a tool that manages those stuff would immensely improve the experience.

On Fri, May 15, 2020, 11:46 PM Max Rydahl Andersen notifications@github.com wrote:

@iocanel https://github.com/iocanel i'm missing something i'm sure but what I hear you say is that the sequence a user will do with this estup is:

git clone project cd project mvn package (generates kubernetes resources and tekton yaml) mvn deploy (does a tkn / kubectl dance to setup a k8s / tekton based build) ... tekton is triggered and does:

git clone project cd project mvn package (generates kubernetes resources and tekton yaml) mvn deploy (this time just do what corresponds. to kubectl apply)

What is the value to that versus:

git clone project cd project add tekton-ci.yml to project git commit/push tekton via webhooks notices project cahgned and uses the tekton-ci.yml and then do: git clone project cd project mvn package (generates kubernetes resources) mvn deploy (this time just do what corresponds. to kubectl apply)

why the meta-generation need instead of just a basic pipeline definition - what am I missing ?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/quarkusio/quarkus/issues/6147#issuecomment-629475702, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADCEWF6WXRJW4JQD34VWRTRRWS2JANCNFSM4J2DG3PA .

maxandersen commented 4 years ago

Okey - yes if we are talking full on raw tekton then yes. I was with the understanding tekton in OpenShift was providing a higher Level yml option where all this low level detail is not required.

Can't see this low level tekton approach be what we want users exposed to; even if pArtial generated.

There is still a chicken and egg problem with this.

maxandersen commented 4 years ago

Something like this is what I thought would make more sense https://github.com/bigkevmcd/tekton-ci

https://bigkevmcd.github.io/tekton-ci/pipeline-run/conversion/2020/05/04/bootstrap-pipeline-run.html

iocanel commented 4 years ago

So you would point users to use an external tool, with a different configuration mechanism that may or may not play nicely with the manifests we generate. Why? Just to avoid the chicken egg (the in-cluster build producing a Tekton manifest)?

On Sat, May 16, 2020, 9:02 AM Max Rydahl Andersen notifications@github.com wrote:

Something like this is what I thought would make more sense https://github.com/bigkevmcd/tekton-ci

https://bigkevmcd.github.io/tekton-ci/pipeline-run/conversion/2020/05/04/bootstrap-pipeline-run.html

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/quarkusio/quarkus/issues/6147#issuecomment-629594256, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADCEWBYVY3LFJHO2W5SDYDRRYUAZANCNFSM4J2DG3PA .

maxandersen commented 4 years ago

what manifests would it not play nice with?

I'm just comparing the experience to ie. Gitlab, GitHubs, Travis, JenkinsX etc. Where the complexity is much less.

Again, I still don't grok what you use to do the first build that generate the ci resources.

iocanel commented 4 years ago

An external tool that is unaware of the quarkus Kubernetes extension would require manual tuning for a lot of things, including:

Location of the Kubernetes extension generated manifests.
Image push secrets
Registry config

That takes a near-zero config experience (which is what I am after) out of the equation.

Note: I am not just talking about a building pipeline, I am talking all the way up to deployment.

Maybe, it should be simpler if I provided a PR so that we can talk about something concrete.

On Sat, May 16, 2020, 10:32 AM Max Rydahl Andersen notifications@github.com wrote:

what manifests would it not play nice well?

I'm just comparing the experience to ie. Gitlab, GitHubs, Travis, JenkinsX etc. Where the complexity is much less.

Again, I still don't grok what you use to do the first build that generate the ci resources.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/quarkusio/quarkus/issues/6147#issuecomment-629602771, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADCEWAZCQ7D6YKH7GYRF5TRRY6RTANCNFSM4J2DG3PA .

lordofthejars commented 4 years ago

My point is tekton is hard, then let's help users in the adoption by providing them a set of tekton tasks specific to Quarkus so we improve the DX. Not developing an external tool or integrating with it but a native tekton experience.

El sáb., 16 may. 2020 11:54, Ioannis Canellos notifications@github.com escribió:

An external tool that is unaware of the quarkus Kubernetes extension would require manual tuning for a lot of things, including:

Location of the Kubernetes extension generated manifests.

Image push secrets

Registry config

That takes a near-zero config experience (which is what I am after) out of the equation.

Note: I am not just talking about a building pipeline, I am talking all the way up to deployment.

Maybe, it should be simpler if I provided a PR so that we can talk about something concrete.

On Sat, May 16, 2020, 10:32 AM Max Rydahl Andersen < notifications@github.com> wrote:

what manifests would it not play nice well?

I'm just comparing the experience to ie. Gitlab, GitHubs, Travis, JenkinsX etc. Where the complexity is much less.

Again, I still don't grok what you use to do the first build that generate the ci resources.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <https://github.com/quarkusio/quarkus/issues/6147#issuecomment-629602771 , or unsubscribe < https://github.com/notifications/unsubscribe-auth/AADCEWAZCQ7D6YKH7GYRF5TRRY6RTANCNFSM4J2DG3PA

.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/quarkusio/quarkus/issues/6147#issuecomment-629619572, or unsubscribe https://github.com/notifications/unsubscribe-auth/AALSMYL2KSB35YHKWIZXMTLRRZPEXANCNFSM4J2DG3PA .

maxandersen commented 4 years ago

Pr will be good. I seriously struggle to see how a “native” Tekton is competitive with existing ci systems declarative formats.

Auto generating ci for a single quarkus project just don’t feel right.

And @lordofthejars a set of tasks means what? A call to mvn ?

lordofthejars commented 4 years ago

Yes, I agree that Tekton is complex but well this is what it is, from Quarkus point of view, I think we only can simplify the experience

Missatge de Max Rydahl Andersen notifications@github.com del dia ds., 16 de maig 2020 a les 13:07:

Pr will be good. I seriously struggle to see how a “native” Tekton is competitive with existing ci systems declarative formats.

Auto generating ci for a single quarkus project just don’t feel right.

And @lordofthejars https://github.com/lordofthejars a set of tasks means what? A call to mvn ?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/quarkusio/quarkus/issues/6147#issuecomment-629628782, or unsubscribe https://github.com/notifications/unsubscribe-auth/AALSMYJXVXURZMZRJBZEZCDRRZXXPANCNFSM4J2DG3PA .

maxandersen commented 4 years ago

Of course we want to simplify what we can here. There are though a big worry for me here we create something that only work with Quarkus and is not extendable where it need to be.

I.e. as soon as your repo as a ui frontend or set of services to build how does that work here ...

The kubernetes extension allow you to go all in Quarkus or mix it up.

Here I'm seeing us hardcode generation of tekton Quarkus specific descriptors

lkrzyzanek commented 3 years ago

I'm trying to figure out how to build Quarkus app with Tekton for a few days. At the beginning I was thinking about some "quarkus tekton task" which could be easily consumable by developers (like maven Tekton task).

But then I realised that what is really needed is just use properly quarkus-container-image-jib quarkus plugin and just correctly configure maven Tekton plugin. That's it.

Here is working example: https://github.com/lkrzyzanek/quarkus-tekton-pipeline-example and pipeline here: https://github.com/lkrzyzanek/quarkus-tekton-pipeline-example/blob/master/pipeline/pipeline.yaml

The build&push Tekton task looks like this then:

    - name: build-push-image
      taskRef:
        name: maven
      runAfter:
        - fetch-repository
      params:
        - name: CONTEXT_DIR
          value: $(params.contextDir)
        - name: GOALS
          value:
            - -Dmaven.repo.local=$(workspaces.local-maven-repo.path)
            - -Dquarkus.container-image.insecure=true
            - -Dquarkus.container-image.registry=example.com
            - -Dquarkus.container-image.build=true
            - -Dquarkus.container-image.push=true
            - -Dquarkus.container-image.group=$(params.imageGroup)
            - -Dquarkus.container-image.name=$(params.imageName)
            - package
      workspaces:
        - name: maven-settings
          workspace: maven-settings
        - name: source
          workspace: shared-workspace

maxandersen commented 3 years ago

Yes. Jib makes this fairly simple.

/cc @quintesse @cescoffier who done some work on this too

lordofthejars commented 3 years ago

What I 'd like is that you could get this file automatically using Dekorate. That would help a lot in Tekton adoption.

cescoffier commented 3 years ago

We still trying to figure out how should look the "ideal" Quarkus Tekton task. There is a range of inputs and outputs (native vs. jvm, mandrel vs. graalvm, gradle vs. maven vs. jbang, jib vs. dockerfile, push to the local registry (openshift) vs. push to an external registry...)

maxandersen commented 3 years ago

@lordofthejars im still struggling the sensical in that to.get the metadata to do the build you first need to do a build :)

lordofthejars commented 3 years ago

well the idea is to be able to scaffold something with mvn before doing the build.

quarkusio / quarkus

Tekton generation resources #6147