Bump tekton to v0.21.0 release

[xiujuan95]

Changes

Bump tekton to v0.21.0 release.

• Changes for go modules and vendor Dependencies
• Modify docs and tekton installation script with new version

Submitter Checklist

• Includes tests if functionality changed/was added
• Includes docs if changes are user-facing
• Set a kind label on this PR
• Release notes block has been filled in, or marked NONE

See the contributor guide
for details on coding conventions, github and prow interactions, and the code review process.

Release Notes

• Tekton dependency change

Tekton version is bumped to v0.21.0

[qu1queee]

/retest

[gabemontero]

The description needs to be updated with the actual release note text. Please add at the bottom

Tekton dependency bumped to v0.21.0

/hold

feel free to cancel the hold once the description is updated.

[gabemontero]

See https://raw.githubusercontent.com/shipwright-io/build/master/.github/pull_request_template.md if you want to verify the precise syntax for the release note .. i.e. 4 back ticks followed by release-note

[imjasonh]

Can we describe the minimum version of Tekton that's required by Shipwright? This makes it seem like 0.21 is the minimum, which might make it harder for people to try out.

Same with minimum Kubernetes versions above; saying 1.15 - 1.18 makes it sound like 1.19+ aren't supported for some reason.

[xiujuan95]

Thanks @imjasonh !
Currently, in our side, we don't have a flow to test the minimum version of tekton for each shipwright-io build release. At present, for each build release, we only bump tekton to the version what we want and test it.

So, to some extent, for a fixed build release, users need to have a fixed tekton version. But yes, indeed, this is a good suggestion. Maybe we can add a flow to test the minimum tekton version for each build release in the future, then we can document it.

[imjasonh]

I understand we might not have tests for every Tekton version, but I think if we believe it works with 0.20 or 0.19 we should document that. If lacking tests is a concern we can invest in that as well. GitHub Actions can run against a matrix of Tekton versions relatively easily if we feel that's necessary to test.

Shipwright should be expected to work with a range of Tekton versions, or else there's no way to upgrade either Tekton or Shipwright safely, since they'd have to be done in lock-step at the same time. Users who have an older Tekton version (even just the previous version) might be scared off to learn they need the absolute latest Tekton release to use Shipwright.

This feedback doesn't need to block this PR, but we should definitely not be documenting that Shipwright only works with one version of Tekton.

[qu1queee]

@imjasonh we tried the matrix before for the k8s version permutations. I think github actions started to behave strange. I need to revisit what was exactly the problem. All I´m trying to say is that infrastructure wise, github might not be ideal for so many flavors of testing, we need to revisit this again.

I see the value on not scaring users in regards of Tekton versions. So we definitely need to do better in here.

I will open a new issue in our backlog that covers:

• How to properly document minimum version for k8s and tekton, for Shipwright users in order to avoid situations as the one you jsut mentioned on might be scared.
• Provide a follow-up on how can we have a test that can continuously test N,N-1,N-2 versions of Tekton and k8s. Plus a layout of pros and cons based on what we found when @SaschaSchwarze0 tried it.

[xiujuan95]

/unhold

[qu1queee]

@xiujuan95 thanks, nice work. This was actually blocked before, but is nice to see that we finally are able to bump our two core dependencies. I´m asking for minor changes, in general the PR looks good.

[qu1queee]

running go mod tidy seems to always want to add a new line, so maybe you should have that one here. Otherwise anyone else running a go mod tidy in the future might experience a change in the go.mod. Does this make sense?

[xiujuan95]

Make sense, done!

[qu1queee]

/lgtm
/approve

[openshift-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: qu1queee

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [qu1queee]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment