Add version label to pipelines controller deployment

[skaegi]

Figuring out which version of Tekton you're running can be a challenge of looking up image SHAs and other equally fun things.

As per https://kubernetes.io/docs/concepts/overview/working-with-objects/common-labels/ we should add an an app.kubernetes.io/version label to the tekton-pipelines-controller deployment and figure out how we set it both for formal versions and ad-hoc builds.

[vdemeester]

/kind feature

[josephlewis42]

Another place I'd like to see this is on the namespace; if you're sharing a cluster a scrupulous operator would probably lock down the controllers, but it's more likely users would have access to read namespaces.

For example, Knative Serving does this with a serving.knative.dev/release label on their namespace. (I like the idea of using the standard K8s label instead of re-inventing the wheel, however.)

[waveywaves]

@vdemeester @chmouel Kubernetes exposes versions leveraging git metadata, the following being the scaffold to it https://github.com/kubernetes/kubernetes/tree/7f23a743e8c23ac6489340bbb34fa6f1d392db9d/staging/src/k8s.io/client-go/pkg/version
This approach would be quite reliable

This doesn't count as a hack right ? 🤔

[chmouel]

@waveywaves Git tagging is good enough for me,

There is multiple part where we can expose this information :

• On the controller
• On the namespace
• as an API (for tools to show)

[vdemeester]

We should definitely expose it using labels on the namespace and/or on the controller/webhook deployments. I'm not sure how we would do "as an API" as I don't think it is supported for CRDs.

[chmouel]

Yes you are right but how can we do to get the version from the tooling tho? (it doesnt know where the namespace is and there can be many pipeline in different installs)

[chmouel]

I think we should reopen this since there is a bit more to it than f85c53f

/reopen

[xcoulon]

Not sure if this would help, but you could use ldflags during build time to set some variables with the commit hash (and optionally tag) and reuse them in the controller at runtime. Something like:

go build ${V_FLAG} \
-ldflags "-X ${GO_PACKAGE_PATH}/version.Commit=${GIT_COMMIT_ID} -X ${GO_PACKAGE_PATH}/version.BuildTime=${BUILD_TIME}" \
-o $(OUT_DIR)/bin/host-operator \
cmd/manager/main.go

see https://github.com/codeready-toolchain/host-operator/blob/master/make/go.mk#L13-L19, https://github.com/codeready-toolchain/host-operator/blob/master/make/git.mk and https://github.com/codeready-toolchain/host-operator/blob/master/version/version.go

[vdemeester]

To recap:

• We have the ldflags thingy (here)
• We have versions labels in our deployments (controller and webhook) (that are updated at release time)

Given the title of the issue, I think we can close 😉

[vdemeester]

/close

[tekton-robot]

@vdemeester: Closing this issue.

In response to this:

/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.

[xcoulon]

To recap:

• We have the ldflags thingy (here)
• We have versions labels in our deployments (controller and webhook) (that are updated at release time)

Given the title of the issue, I think we can close 😉

doh! I should have checked the actual codebase before making this suggestion ;) 🤦‍♂

[chmouel]

we still need an implementation in CLI tho 💃

(but that's nothing to do with this issue, just looking for some volunteers who wants to tackle it since it seems that it has stagnated ;))

[chmouel]

fyi we have an implementation for CLI now!