Fix operatorpolicy confusing status when invalid

[yiraeChristineKim]

Description:
When the subscription section of the OperatorPolicy is invalid, the status might incorrectly indicate that other parts of the policy are invalid. This, combined with the many "... because the policy is invalid" clauses in the overall status, makes it very confusing to read and understand what parts might need to be fixed by the user.

Change summary
Refactored buildResources to simplify control flow, ensure accurate changed propagation, and improve early error reporting.
Added focused unit tests and dryrun tests; refined e2e case38 to reflect new validation behavior and to fix formatting.

Previous results:
The status message was extremely long, for example:
“NonCompliant; installPlanApproval is prohibited in spec.subscription, the namespace specified in spec.operatorGroup ('example') must match the namespace used for the subscription ('openshift-operators'), the status of the OperatorGroup could not be determined because the policy is invalid, the status of the Subscription could not be determined because the policy is invalid, the status of the InstallPlan could not be determined because the policy is invalid, a relevant installed ClusterServiceVersion could not be found, no CRDs were found for the operator, there are no relevant deployments because the ClusterServiceVersion is missing, the status of the CatalogSource could not be determined because the policy is invalid.”
After the fix:
The only meaningful part is now:
“installPlanApproval is prohibited in spec.subscription.”
Everything else was just unnecessary noise and is no longer included.
This part is actually incorrect: "the namespace specified in spec.operatorGroup ('example') must match the namespace used for the subscription ('openshift-operators'),".
Ref: https://issues.redhat.com/browse/ACM-16781

[yiraeChristineKim]

/ok-to-test

[yiraeChristineKim]

/cc @dhaiducek

[JustinKuli]

I was expecting to see some change around where buildResources is called, or where the full compliance message is created - how does this PR shorten the full message to only the relevant part? It seems like when the subscription or operator group are invalid (for example, specifying installPlanApproval), the compliance message will still include the repetitive/confusing "the status of the OperatorGroup could not be determined because the policy is invalid, the status of the Subscription could not be determined because the policy is invalid, the status of the InstallPlan could not be determined because the policy is invalid ..." part. I couldn't find a test that checks for that

[yiraeChristineKim]

I was expecting to see some change around where buildResources is called, or where the full compliance message is created - how does this PR shorten the full message to only the relevant part? It seems like when the subscription or operator group are invalid (for example, specifying installPlanApproval), the compliance message will still include the repetitive/confusing "the status of the OperatorGroup could not be determined because the policy is invalid, the status of the Subscription could not be determined because the policy is invalid, the status of the InstallPlan could not be determined because the policy is invalid ..." part. I couldn't find a test that checks for that

TestBuildResources_subInstallPlanApprovalErrorUpdatesStatus test is for that test with message "installPlanApproval is prohibited in spec.subscription"

[JustinKuli]

LGTM! Thanks for the persistence!

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: JustinKuli, yiraeChristineKim

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

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [JustinKuli,yiraeChristineKim]

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