Populate K8s annotations for outerloop = s2i build - component operator

[cmoulliard]

Feature request

Populate K8s annotations used by the Component Operator prod = outerloop mode according to what is discovered within the current maven project and git repo

For the moment, we hard code the info needed to perform a s2i build using ap4k k8s annotation

https://github.com/snowdrop/component-operator-demo/blob/master/fruit-backend-sb/src/main/java/com/example/demo/CrudApplication.java#L30-L39

@KubernetesApplication(
        annotations = {
                @Annotation(key = "app.openshift.io/artifact-copy-args", value = "*.jar"),
                @Annotation(key = "app.openshift.io/component-name", value = "fruit-backend-sb"),
                @Annotation(key = "app.openshift.io/git-dir", value = "fruit-backend-sb"),
                @Annotation(key = "app.openshift.io/git-ref", value = "master"),
                @Annotation(key = "app.openshift.io/git-uri", value = "https://github.com/snowdrop/component-operator-demo.git"),
                @Annotation(key = "app.openshift.io/java-app-jar", value = "fruit-backend-sb-0.0.1-SNAPSHOT.jar"),
                @Annotation(key = "app.openshift.io/runtime-image", value = "fruit-backend-sb")
        })

but most of the properties could be calculated dynamically by ap4k and added to the yaml/json file

apiVersion: "v1"
kind: "List"
items:
- apiVersion: "component.k8s.io/v1alpha1"
  kind: "Component"
  metadata:
    annotations:
      app.openshift.io/java-app-jar: "fruit-backend-sb-0.0.1-SNAPSHOT.jar"
      app.openshift.io/artifact-copy-args: "*.jar"
      app.openshift.io/git-dir: "fruit-backend-sb"
      app.openshift.io/runtime-image: "fruit-backend-sb"
      app.openshift.io/git-ref: "master"
      app.openshift.io/component-name: "fruit-backend-sb"
      app.openshift.io/git-uri: "https://github.com/snowdrop/component-operator-demo.git"
    labels:
      app: "fruit-backend-sb"
      version: "0.0.1-SNAPSHOT"
      group: "dabou"
    name: "fruit-backend-sb"
  spec:
    deploymentMode: "innerloop"
    runtime: "spring-boot"
    version: "1.5.15.RELEASE"
...

[geoand]

@iocanel By looking at this briefly, my idea was to enhance ComponentHandler to include BuildInfo and use that data in the createComponent method. Does that sound like the proper way to proceed?

[cmoulliard]

Could the BuildInfo class been used for standard s2i build or build managed by our Component Operator ?

[geoand]

BuildInfo is just a collection of data that is pulled from the build system (Maven, Gradle etc). From my limited point of view, it could be used in any context that needs such info.

[cmoulliard]

any context that needs such info

+1

[geoand]

I can implement this, but since there are multiple ways of doing it, I would like @iocanel to confirm or deny whether the idea I had above is good or if there is a more elegant way

[cmoulliard]

WDYT @iocanel ?

[iocanel]

As @metacosm pointed out in our last call, it's not just about BuildInfo but about GitInfo too, which is something that currently we doesn't exist.

I think that we should add it all our processors have access to that kind of information. Now, the ComponentHanlder could be one such place. What needs some thought though is the label names, as I have quite a few questions around them:

Why do we add Opesnhift prefix to our labels? Is Component CRD openshift only?

[iocanel]

@cmoulliard ^

[cmoulliard]

Why do we add Opesnhift prefix to our labels?

They have been prefixed as such according to DevTools Bu convention [1]. I'm not opposite to review/change them

[1] https://github.com/gorkem/app-labels/blob/master/labels-annotation-for-openshift.adoc#labels

[cmoulliard]

Is Component CRD openshift only?

No. It supports k8s and openshift ;-)

[geoand]

I'll leave this one to you folks :). If you want me to implement something, just give me a heads up :)