Common CI/CD workflows - investigation/planning

[maleck13]

What

• Define a common set of workflows that each of our components should put in place. (look at existing ones from GLBC and Authorino etc to see what can be reused
• Once agreed flows are in place define the set of tasks needed for each component and link them into this overall epic

[guicassolato]

Here are a few ideas for automated CI/CD workflows and a brief assessment of the current status of those in the Kuadrant components.

Category	Workflow	Trigger	K	KO	A	AO	L	LO	GLBC
A. Linters & Code style	A1. Built-in auto-format go fmt, go vet, cargo fmt	PR, merge	✓	✓	✓	✓	✓
	A2. 3rd-party linters Reviewdog, golangci-lint, Clippy - Trailing whitespaces, EOF newline, Language-specific	PR, merge	✓		✓		✓		✓
	A3. Spelling client9/misspell	PR, merge	✓		✓
	A4. Language Woke	PR, merge	✓		✓
B. Tests	B1. Unit tests go test, cargo test	PR, merge	✓	✓	✓	✓	✓	✓	✓
	B2. End-to-end tests Build an image → deploy → run integration tests	Merge, manual	✓	✓	✓				✓
	B3. Smoke tests Deploy image from quay.io/kuadrant → run integration tests	After C1			✓
	B4. Performance & Benchmarks	After C1			✓1		✓1		✓
C. CI/CD	C1. Build and push image to quay.io/kuadrant	Merge, After D1	✓2	✓	✓	✓	✓2	✓	✓
	C2. Deploy Shared Kubernetes/OpenShift cluster in the cloud	After B3, after C1, manual							✓
D. Release	D1. Release Tag, version	Manual
E. Code scan (vulnerability, dependency updates)	E1. Dependabot alerts3	Daily	✓		✓		✓		✓
	E2. Dependabot version updates3	Daily
	E3. Dependabot security updates3	Daily	✓		✓
	E4. Code vulnerability scan CodeQL3, Red Hat Dependency Analytics4	Daily	✓
	E5. Static Code Analysis SonarQube5	Daily
F. Badges	F1. Test status & coverage	Merge	✓		✓		✓		✓
	F2. Code analysis (dependencies, security)	After E4-5

^K Kuadrant
^KO Kuadrant Operator
^A Authorino
^AO Authorino Operator
^L Limitador
^LO Limitador Operator
^GLBC Global Load Balancer Controller

¹ Currently set to trigger at every push (PR, merge)
² Currently configured in Quay instead of GHA
³ Configurable in GitHub (Repo > Settings > Code security and analysis)
⁴ Runs as a Visual Studio Code extension
⁵ Red Hat provides it for internal use; possibly not suitable for the upstream

[maleck13]

@guicassolato thanks this is a great visual aid. With C2 the GLBC does have this, it also will very shortly have b4 (pr open)

[guicassolato]

With C2 the GLBC does have this

@maleck13, I saw https://github.com/Kuadrant/kcp-glbc/blob/4a3b8a8c111f66adc5991d14692a940affe16c49/.github/workflows/kcp-glbc-image.yaml#L66. However, this one does not deploy to a shared cluster – or shared clusters (plural), in the case of GLBC. I was thinking on an env where we (engineers), but also QEs and PMs could all log in and try the deployment afterwards. Or maybe you meant some other workflow/step of the GLBC repo?

it also will very shortly have b4 (pr open)

Updated in the table. Thanks!

[maleck13]

It is deployed to a cluster and integrates with a KCP where it could be accessed and used.

[didierofrivia]

Would it make sense to also include automated release?

Like so:

D. Release	D1. Tag	Trigger by deploy
	D2. Version	Manual -> triggers deploy

Those would be related to deploy the images to Quay. Maybe it's possible to include it under the same workflow (?)

[guicassolato]

@didierofrivia

Would it make sense to also include automated release?

Assuming you mean releases to the upstream of course...

Main problem with automating the release is writing the change log, but I guess that could be an input field of the workflow dispatch form? Though it's not as rich text editing as GitHub's release notes editor.

Apart from the release notes, in the operands, releasing essentially consists of picking a Git SHA and assigning a version to it. It's easy.

The operators, on the other hand, usually involve pairing with released versions of the operands', plus modifying a few internals in the code and committing the changes to a release branch. Still doable though.

We have the (manual) release process documented for Authorino.