Repository navigation
ci: the fork e2e lane cannot push an image the PR itself adds #4329
Description
A fork PR that adds a new first-party image can never get a green E2E Tests, and it only finds that out after the whole build has run.
e2e-fork.yaml builds the push allowlist from the base tree only: it checks out git rev-parse HEAD^1, dry-runs make image in every packages/*/*/Makefile carrying an image: target, and keeps the .oci.tar basenames. A new image exists only in the PR's tree, so its name is missing by construction and the push step refuses it.
Hit on #4291, which adds packages/system/capi-providers-infraprovider/images/cluster-api-provider-kubevirt/. Run 35352153928, job "Push fork images + packages artifact":
image 'cluster-api-provider-kubevirt' is not in the base-tree allowlist
The check should stay. It stops a crafted archive name from creating a junk repo under the CI registry, and the comment above it says exactly that. What is wrong is that the same rule also rejects the legitimate case and leaves the contributor nothing to do: a rebase does not help, a re-run does not help, and the image cannot reach the base tree without merging the PR that the missing green is gating.
Two ways out, and I have no strong preference:
- Take image names from the PR's own Makefiles as well, but only for paths the PR adds under
packages/*/*/images/. - Fail at the derivation step instead. It already knows the base-tree names before anything is built, so it could compare them with the head tree's names right there and stop with an explanation rather than after a full build.
Activity
yankawai commentedon Sep 19, 2026
One more change is waiting on the same barrier. #4253 patches kube-ovn and builds the image from
packages/system/kubeovn/images/kubeovn; on main that directory already exists, so the PR went through. Its release-1.6 backport cannot: 1.6 has no image build for that package at all, so any branch that adds one adds a new image by definition, and from a fork it fails the same push step. Details in #4328.From where I sit the second option in your list is the more useful one: failing at the derivation step would have told me before a full build rather than after it.
ci(e2e): refuse a new fork image before the build starts (#4767)