Epic Goal

• As an operator author, I would like my operator to be evaluated for multi-arch readiness by the validator provided in operator-sdk at build time. The errors and warnings generated by this validator would ideally be communicated to me in the same way other validations are done. This would help me identify issues with unset node-affinity boundaries and inconsistencies between operators listed in the operator hub cluster service version manifest and the images built for the operator.

Why is this important?

• Multi-Arch readiness is an important aspect of encouraging teams to consider the effects of deployments that allow for smooth UX with non-amd64 compute nodes as a default experience.

Acceptance Criteria

• multi-arch validator for operator-sdk runs each time an operator is built
• warnings and errors from multi-arch validator are displayed to the author in some sort of build summary

Dependencies (internal and external)
1. Konflux

Previous Work (Optional):
1. N/a

Open questions::
1. N/a

Done Checklist

• CI - For new features (non-enablement), existing Multi-Arch CI jobs are not broken by the Epic
• Release Enablement: <link to Feature Enablement Presentation>
• DEV - Upstream code and tests merged: <link to meaningful PR orf GitHub Issue>
• DEV - Upstream documentation merged: <link to meaningful PR or GitHub Issue>
• DEV - If the Epic is adding a new stream, downstream build attached to advisory: <link to errata>
• QE - Test plans in Test Plan tracking software (e.g. Polarion, RQM, etc.): <link or reference to the Test Plan>
• QE - Automated tests merged: <link or reference to automated tests>
• QE - QE to verify documentation when testing
• DOC - Downstream documentation merged: <link to meaningful PR>
• All the stories, tasks, sub-tasks and bugs that belong to this epic need to have been completed and indicated by a status of 'Done'.