e2e: support testing a change that spans multiple unmerged OADP-ecosystem PRs at once

[kaovilai]

Goal

A PR to kubevirt-datamover-controller (or -plugin, or oadp-operator) should be able to trigger a presubmit that tests all of {oadp-operator PR, kdm-controller PR, kdm-plugin PR} together, before merge — as a normal CI gate, not a manual pre-merge image substitution that then has to be reverted post-merge.

Problem

CI in this ecosystem can only exercise one unmerged PR at a time. A presubmit for repo X can inject X's own PR image into an otherwise-merged/promoted install of everything else, but there's no way to test a change that requires unmerged code in two or more OADP-ecosystem repos simultaneously.

This isn't hypothetical — it already blocks real feature work, and it's not limited to one repo pair:

• kubevirt-datamover: migtools/kubevirt-datamover-controller#84 (concurrency limiter for DU/DD controllers, sub-issues #174/#175) explicitly notes: "The flag is exposed via KubevirtDatamoverConfig in the DPA spec (separate OADP operator PR)" — the feature is inherently split across a kdm-controller PR (adds --max-concurrent-data-movers) and an oadp-operator PR (adds the DPA field, wires it through). Neither PR can be e2e-verified alone.
• velero plugins: a change to openshift-velero-plugin or velero-plugin-for-aws that needs a matching DPA/CSV change in oadp-operator (new plugin config surfaced through the DPA, a new default plugin image reference, etc.) has the same shape — the plugin PR and the oadp-operator PR each only make sense together.
• oadp-non-admin / oadp-cli: features that add a new DPA-adjacent CRD field or CLI flag typically need a companion oadp-operator change (RBAC, CSV, default config) to actually be reachable, same pattern again.

Any pair (or triple) of {oadp-operator, kubevirt-datamover-controller, kubevirt-datamover-plugin, openshift-velero-plugin, velero-plugin-for-aws, oadp-non-admin, oadp-cli, ...} can hit this. This issue is about the general capability, not a kdm-specific one.

Follow-up to

openshift/release#83049 — this issue tracks the "test more than one unmerged PR at once" gap identified in scrum feedback on that PR; it's an enhancement on top of that work (which only solved the single-repo-PR-into-merged-rest case), not a blocker for it.

Rough approaches to evaluate (not yet designed)

None of these are committed to — this issue is to pick one and design it properly, for the general N-repo case:

0. Depends-On: PR-description convention (precedent already exists in this repo). openstack-k8s-operators-kuttl-commands.sh already does exactly this, Zuul-style: it fetches the triggering PR's own body via the GitHub API, greps it for a Depends-On: .../install_yamls/pull/<N> line, extracts <N>, and does git fetch origin pull/$pr_num/head:PR$pr_num && git checkout PR$pr_num against the companion repo's already-cloned source (via a normal extra_refs/git clone -b <branch> for the base) — entirely inside the running job's own script, no bot or custom ProwJob submission needed. For our case this would mean: extra_refs for the companion repo(s)' base branch (so source is present in the pod), plus a step script that parses Depends-On: line(s) out of the triggering PR's body for each companion repo, checks out that PR's HEAD on top, and builds from there. This is likely the strongest candidate: zero new bot/infra, self-updates on every push (normal presubmit re-run), and generalizes to N companion repos by just adding one Depends-On: line per repo.
1. Ad-hoc manual ProwJob submission. For a specific combo, hand-craft a ProwJob CR with extra_refs pinned to each repo's specific PR SHA and submit it directly (oc --context=app.ci create -f prowjob.yaml), per OpenShift CI docs on manually triggering jobs. Zero new infra, but fully manual per combo, easy to get wrong, and doesn't self-update if any linked PR gets a new push.
2. A small chatops/bot-triggered "combo e2e" job. A slash command (e.g. /test combo-e2e oadp-operator=<PR#> kubevirt-datamover-controller=<PR#> velero-plugin-for-aws=<PR#> ..., any subset) that resolves each PR's HEAD SHA via the GitHub API and submits a parameterized ProwJob with extra_refs for all of them, reusing whatever install step the target combo needs. More flexible than the Depends-On: convention (works without editing the PR description) but needs a small bot/script component and somewhere to invoke it from.
3. Generalize the cross-namespace image-mirroring pattern already built in #83049. OO_MIRROR_TO_CLUSTER_REGISTRY already solves "make an image built in one ephemeral job namespace reachable from another job" for a single bundle image. The same pattern (each contributing PR's job builds and pushes its own image somewhere reachable — internal registry, or a scratch tag — then a combo job pulls all of them) could generalize to N images, but each contributing repo's own presubmit would need to actually publish its image somewhere durable enough for a different job to consume, which none of them do today.

Whichever approach is chosen should account for: how a contributor discovers/invokes it, what happens when one of the linked PRs gets a new push mid-run, and scaling cleanly from 2-repo to 3+-repo combos across any of the repo pairs above, not just KDM.

Note

Responses generated with Claude