compute the compatibility versions instead of hardcode versions in test

[Icarus9913]

Description

We noticed that we have a hard-coded kuma version 2.6.10 in the 2.10.* or master test framework, which is out of date but we didn't noticed it:

kuma/test/framework/config.go

Lines 216 to 218 in de16dff

	Compatibility: CompatibilitySuiteConfig{
	HelmVersion: "2.6.10",
	},

Maybe we can use the versions.yml to calculate the current compatibility version.

[Icarus9913]

Another old hard-coded version 2.5.x releated code:

kuma/test/e2e/compatibility/cp_compatibility_kubernetes_multizone.go

Lines 114 to 118 in de16dff

	// then resource is synchronized to Global (The namespace here will need to be updated as soon as the minimum version is 2.5.x
	Expect(err).ToNot(HaveOccurred())
	Eventually(func() (string, error) {
	return k8s.RunKubectlAndGetOutputE(globalCluster.GetTesting(), globalCluster.GetKubectlOptions("kuma-system"), "get", "dataplanes")
	}, "30s", "1s").Should(ContainSubstring("demo-client"))

[lukidzi]

We currently run Helm upgrade E2E tests using the version defined in versions.yaml on a specific branch. We should consider improving this approach.

Ideas:

1. Use Helm to automatically determine the latest version(What about Universal mode in this case?)
2. Expose versions.yaml in the kuma-website, allowing us to fetch the latest versions on all branches.
3. Other suggestions…

[bartsmykla]

Triage: we should rely on the versions.json file available on the website

[github-actions]

This issue was inactive for 90 days. It will be reviewed in the next triage meeting and might be closed.
If you think this issue is still relevant, please comment on it or attend the next triage meeting.

[github-actions]

This issue was inactive for 90 days. It will be reviewed in the next triage meeting and might be closed.
If you think this issue is still relevant, please comment on it or attend the next triage meeting.