add a test to ensure that we don't downgrade versions between branches
(this topic first came up in the context of kubernetes patch version upgrades, but generalizes to what we manage as units)
Example:
- let's consider the case of a kubernetes workload cluster in 1.30, that we upgrade from sylva 1.3 to sylva 1.4
- we don't want to downgrade the patch version for this cluster (it might work, but it could also fail -- it's certainly not typically tested upstream --, and in any case this isn't desirable)
- so we can't upgrade to 1.30.x in release-1.3 before we have upgraded to 1.30.x in release-1.4 (or 1.30.y with y > x)
This happened in !4826 (merged) and went unnoticed for a few weeks, creating confusion about ending up downgrading versions of components that we align with what RKE2 ships with (coredns, multus, etc).
If we generalize, we shouldn't upgrade a component in release-<n> before we have also upgraded it in release-<n+1> (or main if there is no release-<n+1>).
To avoid mistakenly doing this we need to have some MR test to guard this case.
A possible test design would be the following:
- the test would run in
relese-<n>branch and would check that no component version in that branch is more recent than the one use in the branch for next version of Sylva - find what is the next sylva branch:
- if we're in
main, there is no "next sylva" branch, nothing to test - if we're in
release-<n>, try to find arelease-<n+1>branch, if found use it as "next branch", if not found usemainas next branch
- if we're in
- once the next-branch is identified, retrieve "component version information", for both the current branch and the next-branch:
- use
tools/generate_units_documentation.py yaml-datato gather unit version information - use
values.yamlk8s_version_mapto find Kubernetes version information
- use
- for each component present in both branches, compare the versions, and fail if there is an inconsistency