search

shipwright-io / build

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

Bleeding Edge Kubernetes CI #185

Open otaviof opened 4 years ago

otaviof commented 4 years ago

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

Mentioned during community meeting (#174)

zhangtbj commented 4 years ago

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

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

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

qu1queee commented 4 years ago

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

do we want to fix this immediately?

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