multi-pr-prow-plugin: Determine path_alias when testing heterogeneous PRs

[danilo-gemoli]

Revert this #4755 because we are still having troubles.

When a test is run against heterogeneous PRs (see this example) the path_alias of any PR is set in accordance with the ci-operator configuration of the originating PR.

This approach is problematic for several reasons:

1. git fails when cloning two repositories within the same directory
2. when it doesn't (and this looks very suspicious to me), the situation it's even more subtle and confusing since we have now two repositories that coexist on the same location.

This PR tries to address the problem by using the ci-operator config's canonical_go_repository field as path_alias for any PR whose organization and repository matching zz_generated_metadata.org and zz_generated_metadata.repo (for that ci-operator config), leaving it empty "" otherwise.

Assuming the following configuration:

Originating PR: https://github.com/openshift/cluster-api/pull/243

Command: /testwith openshift/cluster-api/master/e2e-aws-capi-techpreview https://github.com/openshift/cluster-capi-operator/pull/385

The tool retrieves this ci-operator config for the originating PR: ci-operator/config/openshift/cluster-api/openshift-cluster-api-master.yaml:

...
canonical_go_repository: sigs.k8s.io/cluster-api
...
zz_generated_metadata:
  branch: master
  org: openshift
  repo: cluster-api

then it generates this git ref for the originating PR:

base_ref: master
org: openshift
path_alias: sigs.k8s.io/cluster-api
pulls:
- author: ...
  number: 243
  sha: ...
repo: cluster-api

and this for the additional one:

base_ref: master
org: openshift
path_alias: ""
pulls:
- author: ...
  number: 385
  sha: ...
repo: cluster-api-operator

As a result, clonerefs clones the repositories within the following directories:

• /go/src/sigs.k8s.io/cluster-api for the originating PR https://github.com/openshift/cluster-api/pull/243
• /go/src/github.com/openshift/cluster-capi-operator for https://github.com/openshift/cluster-capi-operator/pull/385

/cc @deepsm007 @smg247

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: danilo-gemoli

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [danilo-gemoli]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[danilo-gemoli]

@smg247 not sure whether we should take the branch name into account here.

[smg247]

I don't think it matters in practice. It is very unlikely that one branch will be configured to use a different canonical_go_repository than the others. We won't likely ever run into a problem with that.

[smg247]

I am worried that this won't get the proper path alias for the non-originating PR though when the canonical_go_repository is configured there. Have you tested this case?

[danilo-gemoli]

Correct, it won't. I did it on purpose because I wasn't sure of how to handle the problem without making an intrusive change (which I still don't want to do unless we realize that this thing is fundamentally broken).
Suppose the following command:

/testwith openshift/kubernetes/master/okd-scos/e2e openshift/installer#999

The ci-operator config of the originating PR is fully determined:

openshift-kubernetes-master__okd-scos.yaml

so it is the canonical_go_repository.
But what about openshift/installer#999? We should grab the baseRef (assuming main here for simplicity) from the PR and then load:

openshift-installer-main.yaml

but we are still missing the information about the variant, which we do have on the originating PR.
Or we could just always use this pattern and forget about variants 🤷🏻 :

<ORG>-<REPO>-<BASE_REF>.yaml

[smg247]

variants can be ignored. I think there are some subtle bugs around them, but they aren't widely used. Neither is the canonical_go_repository, but I think it is easier to solve.

[danilo-gemoli]

Are you ok with this proposal then or you want me to load the "main" ci-operator configs of any additional PRs and use the canonical_go_repository?

[smg247]

I think we need to take the other canonical_go_repository configs into account, yes. I was hoping that we could do that in the config merging logic.

The idea there would be that the merged config contains all relevant canonical_go_repository values in the list, and then ci-operator knows how to find the right one.

[danilo-gemoli]

This is now resolving the canonical_go_repository by looking at the ci-operator configuration, for every PR, whether it is an originating one or not. Does it make sense?

[openshift-ci]

@danilo-gemoli: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
ci/prow/breaking-changes	21e7e00	link	false	/test breaking-changes

Full PR test history. Your PR dashboard.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.