Fix :latest checker version resolution for compliance-checker >= 6.0.0#24
Merged
Merged
Conversation
Collaborator
|
Thanks for the update. After looking more deeply into the compliance-checker lookup behavior, To sum up, I think the best approach for us is:
|
…e-checker to select latest checker version.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
compliance-checker v6.0.0 removed the
:latestalias. Before this,CheckSuite.checkershad keys likecf:latestalongsidecf:1.11. Now it only has the explicit version. Since esgf-qa was passingcf:latestdirectly toCheckSuite.run_all(), users on CC >= 6.0.0 would hit:KeyError: 'cf:latest'making esgf-qa completely broken unless the exact installed version is passed explicitly (e.g.
-t cf:1.11).The fix moves the
:latestresolution intoesgf-qaitself. The existingget_installed_checker_versions()already loads all registered checkers and builds a sorted list of available versions per checker name. A newresolve_latest_version()function uses that to map"latest"to the actual highest installed version number before the checker strings are handed off to compliance-checker. So-t cf,-t cf:latest,-t wcrp_cmip6:latestall continue to work as before.A couple of related fixes are included:
get_checker_release_versions()hadcheck_suite.checkers.get(checker, "unknown version")._cc_spec_versionwhich crashes withAttributeErrorwhen the key isn't found (since .get() returns the fallback string). Now it falls back to finding the highest versioned key for that checker name."cc6:latest" in checkerstring check inrun_compliance_checker()was hardcoded and would break once versions are resolved. Changed tochecker.split(":")[0] in ("cc6", "mip").Known pre-existing failures
test_args5andtest_args6were already failing before this change. They fail because thewcrp-data-checkerplugin'ssanitize()function does not handlenumpy.datetime64, so consistency output files are never written and Part 2 of the QA run fails.Edit: