release-1.7: unit tests red since release prep rewrote two image refs the tests read #5178

Activity

1. Aleksei Sviridkin (lexfrei)

   self-assigned this

   on Nov 1, 2026
2. github-actions

   added

   triage/needs-triageIndicates an issue needs triage by a maintainerIndicates an issue needs triage by a maintainer

   on Nov 1, 2026
3. Aleksei Sviridkin (lexfrei)

   removed their assignment

   on Nov 1, 2026
4. dosubot commented on Nov 1, 2026

   

   dosubotBot

   on Nov 1, 2026 – with DosuBot

   More actions

   There are already two useful precedents in the tree:

   • For kube-ovn, packages/system/kubeovn/charts/kube-ovn/Chart.yaml has appVersion: "1.15.26". The package’s update target uses that field to stamp the Dockerfile’s upstream VERSION and TAG, and hack/check-kubeovn-image-copies.bats already checks its upstream fixture against it. Comparing the CNI marker with v + that unquoted appVersion would follow the existing upstream-version contract rather than the release image tag. [1] [2] [3]
   • MetalLB’s Helm tests explicitly account for release-prep rewriting image refs: they assert the repository and a full SHA-256 digest while leaving the tag free. That is an existing pattern for a separate collector pinning assertion; the current collector regex alone does not demonstrate helper behavior. [4] [5]

   To reply, just mention @dosu.

   ---

   Share context across your team and agents. Try Dosu.

   
5. Aleksei Sviridkin (lexfrei)

   assigned

   Aleksei Sviridkin (lexfrei)

   and

   Marian Koreniuk (themoriarti)

   and unassigned

   Aleksei Sviridkin (lexfrei)

   on Nov 1, 2026
6. themoriarti commented on Nov 1, 2026

   

   Marian Koreniuk (themoriarti)

   on Nov 1, 2026

   Collaborator

   More actions

   Fix is in #5179 (opened against release-1.7 a few minutes after this issue, so it did not link itself):

   • cni-plugins-staging-contract.bats reads the vendored kube-ovn release from appVersion in packages/system/kubeovn/charts/kube-ovn/Chart.yaml, the field packages/system/kubeovn/Makefile builds the image from. The release flow leaves it alone, so the marker stays a kube-ovn version.
   • vtraces_collector_test.yaml now asserts behaviour, as suggested here: it sets _cluster.images-registry and checks that the registry lands in front of the rendered image and that the image stays digest-pinned. The image name is not in the test any more. Dropping the cozy-lib.image call from the template fails the case; the old regex did not notice that.

   Measured on a clean release-1.7 (a32334a): bats 9/10, helm unittest FAIL; with #5179: 10/10 and 28/28. I also grepped every image/tag literal the Prepare release v1.7.0-rc.3 commit rewrote (41 of them) across *_test.yaml, *.bats and helm snapshots: the only other hit is a fixture inside hack/promote-rewrite-tags_test.bats, which builds its own input. So these two were the whole class on this branch.

   Why it stayed hidden: the promote PR (#5161) carries the release label, and pull-requests.yaml skips the Unit & controller tests job on that label. The stamped tree therefore never met the unit suite until the first backport PR. The e2e skip on that label is justified (the rc was already verified); the unit suite has no cluster and takes ~16 min. Dropping release from that job's if: would have shown this on #5161 before merge. That is the release-prep owners' call, so I am only proposing it here; happy to open the PR for it if wanted. The same two-line test fix applies to main and I will open that separately, otherwise release-1.8 repeats this.
7. Aleksei Sviridkin (lexfrei)

   added 2 commits that reference this issue on Nov 9, 2026

   fix(tests): keep two unit tests green after the release image restamp (…

   ...

   This issue will close once commit ec30722 is merged into the 'main' branch.

   ec30722

   fix(tests): keep two unit tests green after the release image restamp (…

   ...

   This issue will close once commit da7f2c2 is merged into the 'main' branch.

   da7f2c2