Introspect image type and skip for bundle images

[komish]

Related to KFLUXBUGS-1638- This pull request modifies the ecosystem check such that it should no longer fail (or need to be worked around) if the built image is an operator bundle.

The original scope for this issue was to detect the image was a bundle and then skip the remaining checks. I went ahead and added a bundle validation call just because it seemed within reach (see KONFLUX-178). If this implementation is not desirable, I'm happy to return to the original scope (i.e. detect the image is a bundle, then skip the ecosystem application image checks).

Before:

• User builds a bundle image
• This task throws a failure (shows up as a ⚠️) because Preflight (check container) can't find what it's expecting.

Now:

• The image's labels are used to determine if it's a bundle or application image (i.e. would call check operator or check container, respectively) unless explicitly set as a Task parameter.
• Operator bundles are unpacked and have operator-sdk bundle validate called on them. The operatoframework optional suite is called with k8s version set to 1.22. This is modifiable via Task parameters, but seemed like a reasonable default for now to match pre-existing pipelines doing similar things.
• NEW: operator bundles will produce a skipped result
• Application images will go through the same process as before (e.g. preflight check container)

Notable:

• This new version requires the same input parameters as the v0.1 Task (at a minimum) to reduce friction on custom pipeline definitions. All new parameters are optional.
• The k8s-version optional parameter is set for users as a sane default. I didn't want to parse this value in shell scripts.
• The bundle validation call uses the Preflight image because operator-sdk is available there. This implementation is a stop gap until preflight check operator can be executed against the input image (I.e. when a disposable cluster and catalog becomes available).

[EDIT: 2025-02-04] This work was rescoped to just skip for operator bundles, and validating operator bundles will be done in another way through a separate JIRA.

[arewm]

A MIGRATION.md file is needed to instruct users how to upgrade to the new task version. Examples of this file can be found in other tasks which have new task versions.

[arewm]

/ok-to-test

[komish]

@arewm Done - All of the new inputs are optional, so there are no required parameters to note in the migration doc. MIGRATION.md has been added.

I think I got all ShellCheck and yamllint complaints as well.

[arewm]

Oh! We do not currently have the ability to specify a non-breaking version bump. Since this is not a breaking change, should we just keep the task version consistent?

[komish]

I think I'd prefer to leave it as an increment given the underlying logic has changed. I would assume that users can also rollback to 0.1 if something in the 0.2 implementation isn't working for them, which seems useful to me. Open either way.

[komish]

Also, there are new results here - but no removed results. Not sure if that helps justify a 0.2.

[komish]

61cb86f rebases off of main.

[arewm]

@dirgim @hongweiliu17 , you reviewed the initial preflight task. Would you be able to help review this update as well?

[komish]

e38256a addresses lint warnings identified here.

[komish]

29ad54d rebases off of main again.

[dhaiducek]

What's the status here?

[nickboldt]

When can we get this merged so that my scratch-based operator-bundle image won't be tested as if it's a UBI9-based container? https://issues.redhat.com/browse/RHIDP-4220?focusedId=26086287&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-26086287

[dhaiducek]

Slack support workflow initiated for this PR in #konflux-users:

• https://redhat-internal.slack.com/archives/C04PZ7H0VA8/p1731688794142029
• EDIT: thread superseded by https://redhat-internal.slack.com/archives/C04PZ7H0VA8/p1731649788997099

[acornett21]

/lgtm

[rcerven]

/ok-to-test

[rcerven]

/ok-to-test

[dirgim]

LGTM

[hongweiliu17]

lgtm

[dhaiducek]

This needs another /ok-to-test because it's not authored by an owner.

[dirgim]

/ok-to-test

[dhaiducek]

I'm surprised this PR is still open two weeks after approval. What's blocking it from being merged?

[dirgim]

Apologies @komish, there seemed to have been an overlooked issue with this PR - the new task version isn't referenced in the default template-build.yaml.
Note also that the READMEs for individual pipelines that use this task will need to be updated - see PR #1645 for an example.

[dhaiducek]

@dirgim @komish Is this PR ready to go now?

[komish]

@dhaiducek Not yet. I'll try to get this updated this week. Thanks for the reminder ping.

[komish]

/retest

[nickboldt]

Created Oct 24... still waiting for this...

https://media2.giphy.com/media/v1.Y2lkPTc5MGI3NjExaWpzMHl4dnVjeTVvOThweWw1anl2djFhcDJvbG5zbWJhdjhwdWFtbSZlcD12MV9pbnRlcm5hbF9naWZfYnlfaWQmY3Q9Zw/aiL06ZH64pof6/giphy.gif

[bcrochet]

Looks like a rebase may be needed? Otherwise...

/lgtm