Bleeding Edge Kubernetes CI

[otaviof]

Lets make sure the Travis-CI tests are duplicated to test against latest Kubernetes versions, and therefore in advance, we will be notified about compatibility problems that either the operator, or surrounding tooling (like operator-sdk) may have.

[otaviof]

Mentioned during community meeting (#174)

[zhangtbj]

Hi @otaviof ,

I think we also need to think about the solution when using Travis:

1, How to test different latest and stable kube versions AND tekton versions in Travis, by using different branches, or? (Just two different tests? latest kube and tekton, stable kube and tekton?)

2, Is there a better way to auto-detect the latest and stable kube AND tekton versions and install the related kube version by KinD by Travis?

[otaviof]

Hi @otaviof ,

👋

I think we also need to think about the solution when using Travis:

1, How to test different latest and stable kube versions AND tekton versions in Travis, by using different branches, or? (Just two different tests? latest kube and tekton, stable kube and tekton?)

I think we can add more jobs to Travis-CI, and make sure KinD uses the latest available Kubernetes cluster for testing, and possibly in parallel, testing against supported versions of Kubernetes.

So just, two different test jobs in Travis-CI would do, in my opinion.

2, Is there a better way to auto-detect the latest and stable kube AND tekton versions and install the related kube version by KinD by Travis?

We install KinD via go get here, thus we can inform different versions, and use no-version as latest KinD available.

However, for Tekton I think we should follow the regular go mod update cycle. Internally those resources are employed, and we may need to adjust the code before updating the Tekton backend supported version.

[zhangtbj]

👍 , it is cool if Travis can run two different jobs in parallel! :)

[qu1queee]

Ok, I like this to be only a matter of the Kind node version. This is very simple, in the travis.yml you should use something like:

env:
- KIND_VERSION=X
- KIND_VERSION=Y

then consume KIND_VERSION in https://github.com/redhat-developer/build/blob/master/hack/install-kind.sh#L13 and that will trigger 2 runs of the tests in different Kinds.

Playing the role of the bad guy here: I get the point on knowing in advance if a very new k8s version will break us,but I would like to know the step after that, do we want to fix this immediately? while if not, this will imply all PRs to be red for a while. Also, do we need to know this if neither IKS/openshift is using this versions(time consuming concern)

[sbose78]

do we want to fix this immediately?

We should prioritize fixing that I would say - unless we have a good reason not to :)