fix(compliance): Handle custom rules when calculating ParentRule#19439
Draft
guzalv wants to merge 3 commits intomaster-base/gualvare/ROX-33477-update-ssb-logic-to-handle-tpfrom
Conversation
Contributor
Author
|
This change is part of the following stack:
Change managed by git-spice. |
|
Skipping CI for Draft Pull Request. |
This solves the issue but injects fake data - custom rules don't have the annotation. Let's implement this in the central converter instead - we have all the data required there. This reverts commit 4cd180b.
3591ce2 to
39c9b2c
Compare
51dd86e to
3416948
Compare
This was referenced Mar 16, 2026
Contributor
|
Images are ready for the commit at 3416948. To use with deploy scripts, first |
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
2 participants
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.
Description
This PR handles the fact that Compliance Operator treats Rules and CustomRules differently when connecting them with the CheckResults they generate:
Check results always have a
compliance.openshift.io/ruleannotation, but it is built differently based on whether they come from aRuleor aCustomRule:Rules, theircompliance.openshift.io/ruleannotation _____WIP:ComplianceOperatorRuleV2 objects with OperatorKind=CUSTOM_RULE had a broken join with their ComplianceCheckResults.
The join key (RuleRefId) is a deterministic UUID derived from BuildNameRefID(clusterID, parentRule), where parentRule is the value of the compliance.openshift.io/rule annotation. For regular rules, CO sets this annotation on Rule objects, so parentRule is populated correctly on ingest.
For CustomRule objects, CO does not set that annotation — CustomRule is a separate CRD and the annotation convention belongs to Rule. CO's CEL scanner derives the check result annotation from Spec.ID via IDToDNSFriendlyName. As a result, parentRule was always empty for custom rules, producing a RuleRefId
that never matched any check result, breaking the join and causing "Unable to process compliance rule" errors in the UI.
Fix: in the rule converter, detect CUSTOM_RULE kind and derive parentRule from RuleId (which carries Spec.ID) using the same IDToDNSFriendlyName transformation CO applies when setting the check result annotation.
User-facing documentation
Testing and quality
Automated testing
How I validated my change
change me!