build

build copied to clipboard

Idea:

This is a follow-up from this PR discussion. At the moment is not clear for users:

• which is the minimal version and latest version that Shipwright supports for Tekton
• which is the minimal version and latest version that Shipwright supports for k8s

We need to provide more clarity on the above, so that users that run on an older version of these dependencies are aware that there is no need to force a bump on their side, in order to use Shipwright.

At the same time, we do not have a mechanism in place to test different versions for the core dependencies, so it makes it harder to properly document this.

As an initial step, we might want to define:

• How do we express the versions we support for Kubernetes, would that be N(latest) plus N-1 and N-2?
• How do we express the versions we support for Tekton, would that be N(latest) plus N-1 and N-2?
• How can we test all permutations of the above core dependencies? git-actions ?
  • @SaschaSchwarze0 tested this at some point via https://github.com/shipwright-io/build/pull/611, but this turns out to provide a lot of instability when running the tests. So this was reverted via https://github.com/shipwright-io/build/pull/614, so that we only test a single k8s version.

@qu1queee I believe #669 will fix this, correct?

@adambkaplan not 100%, I think the goal is:

Document all versions that we support for k8s and Tekton

The idea behind that is:

Avoid as much as possible to force users to bump their k8s/Tekton only because of Shipwright

The current problem:

• [1] We do not know which versions of Tekton we can support, because we do not have the right testing in place to build a matrix of versions and test them continuously.
• [2] We know which versions of K8S we support, but we might not know this in the future, because we do not have the right testing in place to build a matrix of versions and test them continuously.

I think this issue is currently looking for feedback on how to achieve [1] [2].