Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[ISV-5446] static check for catalog bundle images #753

Merged
merged 5 commits into from
Dec 16, 2024
Merged

[ISV-5446] static check for catalog bundle images #753

merged 5 commits into from
Dec 16, 2024

Conversation

mantomas
Copy link
Contributor

@mantomas mantomas commented Dec 6, 2024

This PR adds logic to validate file based catalogs in static checks, with first fbc check check_bundle_images_in_fbc.

Example pipeline run can be found here. The validation is done thanks to config.yaml key allowed_bundle_registries. In the test run two catalogs were updated, but only one failure is detected, as one of the bundles use allowed registry.

If the key allowed_bundle_registries is missing in config.yaml, then the bundle image validation is internally skipped (without the config the new check is turned off).

Closes ISV-5446

@mantomas mantomas requested review from Allda and tomasbakk December 9, 2024 07:29
catalogs = OperatorCatalogList(
[
catalog
for catalog in operator.all_operator_catalogs()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not sure if I understand this loop. The affected_catalogs.split(",") returns a list of strings, right? The operator.all_operator_catalogs() returns a list of OperatorCatalog. And then you compare if OperatorCatalog in a list of strings. How it this going to work? Or am I missing anything here?

Also if you already have a list of affected catalogs, why don't you initiate it directly using OperatorCatalog(<path_to_operator_catalog>) constructor and instead use an operator and its edge to get to it? If we ever make these types completely independent (operator and operatorCatalog) it won't work.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Operator catalog is comparable to string and it works both ways.

I don't understand what you mean by If we ever make these types completely independent? Is there such a plan? As of now, we always have an Operator (as it is affected by the catalog change iirc) and using the edge give me all its catalogs. I can see that there is the way to get specific catalog like OperatorCatalog(repo.root / "catalogs" / "v4.13/kiali") - for me having the path already provided by the Operator sounds more straightforward, but I am open to discussion.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changed the logic to use repo.catalog_path()

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Allda I reverted this logic back to use the operator to operator_catalogs edge - the affected_catalogs contain also removed catalogs and this way we can filter them out. Initiate catalog directly OperatorCatalog(<path_to_operator_catalog>) raise exception for deleted operator catalogs.

Copy link
Contributor

@Allda Allda left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The are couple of things that need to be fixed or updated. Please also add the new test into a documenation https://github.com/redhat-openshift-ecosystem/operator-pipelines/blob/main/docs/users/static_checks.md

@openshift-merge-robot openshift-merge-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Dec 9, 2024
@openshift-merge-robot openshift-merge-robot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Dec 10, 2024
@mantomas
Copy link
Contributor Author

I did some updates and to verify the results run the pipeline for FBC and also integration tests - both with expected results.

@mantomas mantomas requested a review from Allda December 11, 2024 08:35
@mantomas mantomas merged commit d169ca7 into main Dec 16, 2024
9 checks passed
@mantomas mantomas deleted the ISV-5446 branch December 16, 2024 10:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants