[reproducer] Add dependencies compability file for pull

[evallesp]

This file in conjuction with:

• [install_yamls] Add install_yamls pull repo capability #3774
• [repo_setup] Add version for repo_setup repo pull action #3772

Allows ci-framework to clone those repos (architecture was already enabled)
when repositories are not already there due to zuul has not marked them as
required-projects or because we're running them outside the zuul ecosystem.

This is the almost the lowest in precedence, so if we still have these vars defined at zuul
level or defaults-vars (passed as extra-vars) or scenarios files, this file is not
taken into consideration.

Precedence chain:
* Zuul repos
* cifmw_reproducer_repositories
* cifmw_reproducer_default_repositories
* Git pull logic in each of the roles

Signed-off-by: Enrique Vallespi Gil evallesp@redhat.com

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign fultonj for approval. For more information see the Code Review Process.

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

Details

Needs approval from an approver in each of these files:

• OWNERS

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

[softwarefactory-project-zuul]

Build failed (check pipeline). Post recheck (without leading slash)
to rerun all jobs. Make sure the failure cause has been resolved before
you rerun jobs.

https://softwarefactory-project.io/zuul/t/rdoproject.org/buildset/0e59f4afe0e5455a8103a063a29d8f60

✔️ openstack-k8s-operators-content-provider SUCCESS in 2h 18m 52s
✔️ podified-multinode-edpm-deployment-crc SUCCESS in 1h 24m 11s
✔️ cifmw-crc-podified-edpm-baremetal SUCCESS in 1h 22m 29s
✔️ cifmw-crc-podified-edpm-baremetal-minor-update SUCCESS in 2h 04m 41s
✔️ cifmw-pod-zuul-files SUCCESS in 6m 30s
✔️ noop SUCCESS in 0s
✔️ cifmw-pod-ansible-test SUCCESS in 10m 21s
✔️ cifmw-pod-pre-commit SUCCESS in 9m 20s
❌ cifmw-molecule-operator_deploy FAILURE in 13m 20s
❌ cifmw-molecule-reproducer FAILURE in 13m 14s

[evallesp]

Actually, the precedence chain in the PR description makes an assumption for repo_setup, as we need to set the var as done in tcib: https://github.com/openstack-k8s-operators/ci-framework/blob/main/scenarios/centos-9/tcib.yml#L3

As this job is pulling it from zuul: https://github.com/openstack-k8s-operators/ci-framework/blob/main/zuul.d/tcib.yaml#L10 if we set cifmw_repo_setup_src as a any "https://github" url repository, then https://github.com/openstack-k8s-operators/ci-framework/pull/3772/changes#diff-c9e567935c762e94b13ba6e23ac4b630f1f6d0ddc4ffaad77f173274980901d8L24 is overwritten.

repo_setup: Takes url or local folder and move to tmp.
Other roles, the destination is global, as update: false, we're maintaining the precedence, we don't mind variables, the dest is an already git repo and update is false.

Adding in repo-setup the versioning, we're not making the problem bigger.

[michburk]

I see that in many cases, you are defining variables here in group_vars/all.yml, and in role defaults. For example, cifmw_kustomize_deploy_architecture_repo_version is defined both here, and in roles/kustomize_deploy/defaults/main.yml.

This is fine, and according to Ansible's var precedence, the group_vars definitions will be higher precedence than the definitions in the role defaults, so things should act as we're expecting here.

With that being said, though, I don't like moving a var with a role-specific name like cifmw_kustomize_deploy_architecture_repo_version to group_vars, and I think we can be more explicit about where the definition for a specific variable is coming from. As-is, it's confusing to have a role's default var being overwritten by some definition in a completely separate directory. We should either only define these values in group_vars, or, sticking with the cifmw_kustomize_deploy_architecture_repo_version var for example:
We could define a var in group_vars/all.yml like:

cifmw_architecture_repo_version_pin: "HEAD"

(or some other name, this is just an example)
then in the roles/kustomize_deploy/defaults/main.yml file - define:

cifmw_kustomize_deploy_architecture_repo_version: "{{ cifmw_architecture_repo_version_pin }}"

(or maybe even

cifmw_kustomize_deploy_architecture_repo_version: "{{ cifmw_architecture_repo_version_pin | default('HEAD') }}"

? Though maybe we shouldn't silently continue and fall back to a different version than we're expecting to be set from group_vars?)

Though this is more verbose, it clearly explains where the var's value is coming from. Rather than expecting readers to keep group vars and Ansible variable precedence in mind when trying to understand where the actual value of a var is coming from, you can clearly see that the default var's value is subject to change according to a definition that happens somewhere else in the repo.