Add some more validations

[cjeanner]

Ensure we're consuming projects from the same source.

[openshift-ci]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[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 ask for approval from cjeanner. For more information see the Kubernetes Code Review Process.

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

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

[viroel]

shouldn't we worry about default values for this var here? IIRC it defaults to upstream

[cjeanner]

we need to extend the whole thing. For now, it doesn't check the value, but only the consistency. It's weak, to be fair, and we probably want/need something better here, to ensure we're in the right context.

I don't know if we could get anything from within zuul env showing "where" we run, and create some "validation map" stating something like this:

cifmw_src_base_validation:
  upstream:
    src_base: https://github.com/openstack-k8s-operators
    branch: main
  downstream_trunk:
    src_base: /home/zuul/src/....
    branch: trunk  # whatever it should be
  downstream_18_proposed:
    src_base: https://github.com/openstack-k8s-operators.
    branch: 18.0-proposed  # whatever it should be

That would really consolidate the whole thing. Any thoughts? Of course, it must be extensible in an easy way, to be future proof (new branch, new entry in the mapping).

[viroel]

length == 1 , no?

[cjeanner]

woops, right.

[cjeanner]

IMHO it's a good opportunity to extract the validations in their own role. @lewisdenny you created the initial validations.yml in the reproducer role - any thoughts on extracting them all in a "cifmw_validations" or something like that, with dedicated tasks files maybe?
For the git checks, we could even leverage some deeper inspections with re-usable tasks files, loops and all.

Of course, we'll have to keep some parameters allowing to disable the validations - maybe per "validation groups". We can discuss this and, if you're willing to tackle that, we can do some proper handover :)

[lewisdenny]

IMHO it's a good opportunity to extract the validations in their own role. @lewisdenny you created the initial validations.yml in the reproducer role - any thoughts on extracting them all in a "cifmw_validations" or something like that, with dedicated tasks files maybe? For the git checks, we could even leverage some deeper inspections with re-usable tasks files, loops and all.

Of course, we'll have to keep some parameters allowing to disable the validations - maybe per "validation groups". We can discuss this and, if you're willing to tackle that, we can do some proper handover :)

Yeah it would be nice to support some different types/groups of validations, a role would be best. Let's get a Jira card created and we can flesh it out :)

[github-actions]

This PR is stale because it has been for over 15 days with no activity.
Remove stale label or comment or this will be closed in 7 days.