Add tekton operator to local dev cluster

[SchahinRohani]

Description

This PR introduces the Tekton operator with a TektonConfig to replace the existing Tekton pipelines, triggers, and dashboard.

Known Issue:

There is currently a bug where we are only waiting for 60 seconds for the webhooks, instead of checking if they have reached a running/ready status, so there is a possibility that the tekton-webhooks are in an unready state when trying to deploy the tasks, pipelines and triggers.

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)

Checklist

• PR is contained in a single commit, using git amend see some docs

---

This change is 

[SchahinRohani]

Is this PR better @MarcusSorealheis ?

[aaronmondal]

A very nice improvement!

Reviewed 5 of 5 files at r1, all commit messages.
Reviewable status: 0 of 2 LGTMs obtained, and all files reviewed, and 3 discussions need to be resolved

---

native-cli/components/embedded/tekton-config.yaml line 1 at r1 (raw file):

---

I believe this can be simplified by using kustomize to patch the default configuration. This way it'll also be clearer where we deviate from defaults.

---

native-cli/components/embedded/tekton-config.yaml line 2 at r1 (raw file):

---
apiVersion: operator.tekton.dev/v1alpha1

I remember running into issues where the operator had incompatible api versions. Why does this config work without adjustments to the pipeline implementations? I assume some config option here sets the api versions?

---

native-cli/programs/local.go line 83 at r1 (raw file):

			Dependencies: slices.Concat(
				cilium,
				tektonOperator,

Flux shouldn't depend on the tekton operator.

It seems like a good idea to make flux depend on cilium though. Looks like this was an oversight in the previous implementation.

[SchahinRohani]

Reviewable status: 0 of 2 LGTMs obtained, and 2 of 5 files reviewed, and pending CI: Bazel Dev / ubuntu-22.04, Cargo Dev / macos-13, Cargo Dev / ubuntu-22.04, Installation / macos-13, Remote / large-ubuntu-22.04, docker-compose-compiles-nativelink (22.04), macos-13, ubuntu-20.04 / stable, ubuntu-22.04 / stable, windows-2022 / stable, and 3 discussions need to be resolved

---

native-cli/programs/local.go line 83 at r1 (raw file):

Previously, aaronmondal (Aaron Siddhartha Mondal) wrote…

Flux shouldn't depend on the tekton operator.

It seems like a good idea to make flux depend on cilium though. Looks like this was an oversight in the previous implementation.

Done.

---

native-cli/components/embedded/tekton-config.yaml line 1 at r1 (raw file):

Previously, aaronmondal (Aaron Siddhartha Mondal) wrote…

I believe this can be simplified by using kustomize to patch the default configuration. This way it'll also be clearer where we deviate from defaults.

I reworked it and now we fetch it from tektoncd itself and apply the changes in that step. It's kinda the way you did it before.

---

native-cli/components/embedded/tekton-config.yaml line 2 at r1 (raw file):

Previously, aaronmondal (Aaron Siddhartha Mondal) wrote…

I remember running into issues where the operator had incompatible api versions. Why does this config work without adjustments to the pipeline implementations? I assume some config option here sets the api versions?

I just took the latest version of the config and it works.

[aaronmondal]

Reviewed 3 of 3 files at r2, all commit messages.
Reviewable status: 1 of 2 LGTMs obtained, and all files reviewed, and 1 discussions need to be resolved

---

native-cli/components/tekton.go line 70 at r2 (raw file):

func waitForTektonToBeReady() bool {
	// Simulate Tekton State Gathering
	time.Sleep(60 * time.Second) //nolint:mnd

nit: Create an issue that this should use a proper polling mechanism and reference that issue as a TODO here. This way it's clear that this is a workaround.

[aaronmondal]

@SchahinRohani Could you rebase this? It's likely more reliable than the current setup and will make it easier for me to move it over to flux.

[SchahinRohani]

@aaronmondal rebased.

Reviewable status: 1 of 1 LGTMs obtained, and 3 of 5 files reviewed, and 1 discussions need to be resolved

[aaronmondal]

Reviewed 2 of 2 files at r3, all commit messages.
Reviewable status: complete! 1 of 1 LGTMs obtained, and all files reviewed