Skip to content

Conversation

@xiaojiey
Copy link

@xiaojiey xiaojiey commented Dec 2, 2025

Overview

  1. This PR adds support for tracking Component Readiness for the Compliance Operator as a separate layered product dashboard. The Compliance Operator includes both upstream (ComplianceAsCode) and downstream testing, and we need dedicated dashboards to track readiness across these components.

  2. Component Readiness views are added for Compliance across actively supported OCP versions (4.16-4.21).

Changes

  1. Configuration Views (config/views.yaml)

Added Component Readiness views for Compliance across OCP versions:

  • 4.22-lp-Interop-compliance: Compares 4.22 vs 4.21
  • 4.21-lp-Interop-compliance: Compares 4.21 vs 4.20
  • 4.20-lp-Interop-compliance: Compares 4.20 vs 4.19
  • 4.19-lp-Interop-compliance: Compares 4.19 vs 4.18
  • 4.18-lp-Interop-compliance: Compares 4.18 vs 4.17
  • 4.17-lp-Interop-compliance: Compares 4.17 vs 4.16
  • 4.16-lp-Interop-compliance: Compares 4.16 vs 4.15
  1. All views are configured with:
  • LayeredProduct filter: lp-interop-compliance
  • Platforms: azure, gcp, aws
  • Architectures: amd64, arm64
  • Owners: eng, qe
  • Metrics and regression tracking: enabled
  • Base releases use ga-30d to ga for GA'd releases
  1. Suite Registration (pkg/db/suites.go)
  • Added Compliance-lp-interop to the test suites list
  1. Variant Registry (pkg/variantregistry/ocp.go)
  • Added mapping rules for compliance jobs tagged as LayeredProduct lp-interop-compliance:
    • Jobs containing -complianceascode- (upstream tests)
    • Jobs containing -compliance-destructive (downstream destructive tests)
    • Jobs containing -compliance (downstream tests)
  1. Snapshot (pkg/variantregistry/snapshot.yaml)
  • Updated 66 compliance job entries to use LayeredProduct: lp-interop-compliance

Related Jobs

This tracks the following Compliance periodic jobs:

Upstream (ComplianceAsCode) Jobs:

  • periodic-ci-ComplianceAsCode-content-master-{version}-e2e-aws-openshift-node-compliance (amd64/arm64)
  • periodic-ci-ComplianceAsCode-content-master-{version}-e2e-aws-openshift-platform-compliance (amd64/arm64)

Downstream Jobs:

  • periodic-ci-openshift-openshift-tests-private-release-{version}-{arch}-nightly-{platform}-*-compliance
  • periodic-ci-openshift-openshift-tests-private-release-{version}-{arch}-nightly-{platform}-*-compliance-destructive

Coverage includes versions 4.12-4.21 across amd64, arm64, and multi architectures on platforms: aws, azure, gcp, baremetal, vsphere.

  1. Testing
  • Views follow the established naming pattern: {OCP_RELEASE}-lp-Interop-{product}
  • Configuration aligns with other LP-Interop views (CNV, Quay, ServiceMesh, COO, etc.)
  • Metrics and regression tracking enabled for proactive monitoring
  • Both engineering and QE owned jobs are included for comprehensive coverage

Summary by CodeRabbit

  • New Features

    • Added multiple historical lp-interop-compliance releases for broader readiness and aligned release anchors.
    • Expanded variant dimensions to include additional architectures, platforms, layered-product options, and owners for cross-release comparison.
  • Tests

    • Introduced a dedicated compliance test suite and consolidated periodic snapshots under the compliance grouping.
  • Chores

    • Standardized configuration and snapshot defaults for compliance-oriented variants.

✏️ Tip: You can customize this high-level summary in your review settings.

@openshift-ci-robot
Copy link

Pipeline controller notification
This repo is configured to use the pipeline controller. Second-stage tests will be triggered either automatically or after lgtm label is added, depending on the repository configuration. The pipeline controller will automatically detect which contexts are required and will utilize /test Prow commands to trigger the second stage.

For optional jobs, comment /test ? to see a list of all defined jobs. To trigger manually all jobs from second stage use /pipeline required command.

This repository is configured in: automatic mode

@openshift-ci openshift-ci bot requested review from deepsm007 and stbenjam December 2, 2025 05:08
@openshift-ci
Copy link
Contributor

openshift-ci bot commented Dec 2, 2025

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: xiaojiey
Once this PR has been reviewed and has the lgtm label, please assign deepsm007 for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@coderabbitai
Copy link
Contributor

coderabbitai bot commented Dec 2, 2025

Walkthrough

Adds lp-interop-compliance readiness config blocks, registers a "Compliance-lp-interop" test suite, maps compliance-related job name patterns to the lp-interop-compliance layered product, and updates periodic CI snapshots to set LayeredProduct: lp-interop-compliance.

Changes

Cohort / File(s) Summary
Readiness configuration blocks
config/views.yaml
Adds multiple component_readiness YAML entries for historical releases *-lp-Interop-compliance (4.16–4.22), each defining base_release, sample_release, variant_options, include_variants, advanced_options, metrics, regression_tracking, and prime_cache.
Test suite registration
pkg/db/suites.go
Adds "Compliance-lp-interop" to the testSuites slice so the suite will be created/populated by DB population logic.
Layered product routing
pkg/variantregistry/ocp.go
Extends setLayeredProduct mappings so job-name substrings -complianceascode-, -compliance-destructive, and -compliance map to lp-interop-compliance.
Periodic job snapshots
pkg/variantregistry/snapshot.yaml
Changes LayeredProduct from none to lp-interop-compliance across numerous periodic CI snapshot entries.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

🚥 Pre-merge checks | ✅ 6 | ❌ 1
❌ Failed checks (1 warning)
Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Write docstrings for the functions missing them to satisfy the coverage threshold.
✅ Passed checks (6 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The PR title directly and clearly describes the main change: adding Component Readiness dashboard support for the Compliance Operator as a LayeredProduct, which aligns with the actual file changes (config views, test suites, variant registry mappings, and snapshot updates).
Go Error Handling ✅ Passed Go code changes are minimal and do not introduce error handling concerns. Modifications only add string literals and mappings without error-prone operations.
Sql Injection Prevention ✅ Passed This pull request only adds YAML configuration and simple string mappings in Go code, with no SQL query construction or database interactions modified. Therefore, there is no risk of SQL injection introduced by these changes.
Excessive Css In React Should Use Styles ✅ Passed This pull request modifies only Go backend files and YAML configuration files, not React components or frontend styling code, making this inline CSS check inapplicable.
Single Responsibility And Clear Naming ✅ Passed Pull request demonstrates clear naming conventions with descriptive identifiers (lp-Interop-compliance, Compliance struct) and appropriate package organization separating concerns between db/suites.go and variantregistry/ocp.go.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing touches
  • 📝 Generate docstrings


📜 Recent review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Cache: Disabled due to data retention organization setting

Knowledge base: Disabled due to data retention organization setting

📥 Commits

Reviewing files that changed from the base of the PR and between fd89f14 and 63d8502.

📒 Files selected for processing (4)
  • config/views.yaml
  • pkg/db/suites.go
  • pkg/variantregistry/ocp.go
  • pkg/variantregistry/snapshot.yaml
🚧 Files skipped from review as they are similar to previous changes (2)
  • pkg/variantregistry/ocp.go
  • pkg/db/suites.go
🔇 Additional comments (3)
config/views.yaml (3)

2499-2543: LGTM - 4.22-lp-Interop-compliance view is correctly configured.

The configuration appropriately uses now-30d/now for the 4.21 base release (since 4.21 is not yet GA) and correctly sets regression_tracking: enabled: false per reviewer feedback. The variant filters align with the PR objectives for Compliance Operator coverage.

Minor observation: The YAML formatting style differs slightly from existing views (e.g., list items are indented under keys with - amd64 at 8 spaces vs. 6 spaces in existing views, and {} vs { }). Consider aligning with the existing file style for consistency.


2544-2588: LGTM - Correctly uses GA dates for 4.20 base release.

The ga-30d/ga relative time references are appropriate for comparing against the 4.20 GA release, which addresses the previous review feedback about GA date references.


2589-2813: LGTM - Remaining compliance views follow consistent patterns.

Views for releases 4.16 through 4.20 are correctly configured:

  • Each view compares sample release N against base release N-1
  • All use ga-30d/ga time references for their respective GA base releases
  • regression_tracking: enabled: false is consistently set across all views
  • Variant configurations are uniform across all blocks

✏️ Tip: You can disable this entire section by setting review_details to false in your review settings.

Warning

There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure.

🔧 golangci-lint (2.5.0)

Error: can't load config: unsupported version of the configuration: "" See https://golangci-lint.run/docs/product/migration-guide for migration instructions
The command is terminated due to an error: can't load config: unsupported version of the configuration: "" See https://golangci-lint.run/docs/product/migration-guide for migration instructions


Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

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

Actionable comments posted: 1

📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Cache: Disabled due to data retention organization setting

Knowledge base: Disabled due to data retention organization setting

📥 Commits

Reviewing files that changed from the base of the PR and between dfcbb55 and d1bdd22.

📒 Files selected for processing (4)
  • config/views.yaml (1 hunks)
  • pkg/db/suites.go (1 hunks)
  • pkg/variantregistry/ocp.go (1 hunks)
  • pkg/variantregistry/snapshot.yaml (66 hunks)
🔇 Additional comments (5)
pkg/db/suites.go (1)

60-71: New Compliance-lp-interop suite entry looks correct

Adding "Compliance-lp-interop" alongside the other *-lp-interop suites cleanly extends the set of suites we persist into the DB and aligns with the new compliance readiness flow. There are no behavioral concerns with this change itself.

One thing to double-check: ensure the underlying JUnit data (BigQuery testsuite values) for the new compliance jobs actually uses this exact string; any mismatch would mean those results are still filtered out here.

pkg/variantregistry/snapshot.yaml (1)

1173-1728: Verify that the snapshot changes align with the supporting configuration updates.

The changes update 66 CI job entries, changing LayeredProduct: none to LayeredProduct: lp-interop-compliance. While the bulk pattern is consistent, confirm:

  1. Is this the correct change location? Verify whether snapshot.yaml is manually maintained or auto-generated. If auto-generated, ensure the generation process (potentially triggered by changes to config/views.yaml, pkg/variantregistry/ocp.go, or pkg/db/suites.go) is part of this PR workflow.

  2. Job coverage completeness. Ensure all and only the correct compliance-related jobs are being categorized under lp-interop-compliance to prevent missing jobs from the compliance dashboard.

  3. Integration validation. Verify that these snapshot updates, combined with supporting configuration changes, enable the Component Readiness dashboard for Compliance Operator as intended.

config/views.yaml (2)

1507-1507: Note: Lower minimum_failure threshold for new dashboard.

The minimum_failure is set to 2, which is lower than the standard threshold of 3 used in main views (e.g., line 68). This lower threshold means tests will be flagged as problematic with fewer failures, which could be appropriate for a new compliance dashboard to catch issues early, but may also result in more false positives if compliance jobs are less stable.

This appears intentional for initial compliance tracking sensitivity, similar to other specialized views like 4.21-LP-Interop (line 334).


1497-1506: Verify the intentionally limited platform and owner scope.

The compliance view is restricted to:

  • Platform: only aws (line 1505)
  • Owner: only eng (line 1503)

This is notably more restrictive than other views, which typically include multiple platforms (aws, azure, gcp, metal, rosa, vsphere) and owners (eng, service-delivery). Additionally, the view lacks filters for Installer, Network, Topology, and FeatureSet that are standard in other component readiness views.

If this is the initial rollout scope, consider documenting this in the PR description or a comment. Otherwise, verify whether this limited scope is intentional.

pkg/variantregistry/ocp.go (1)

1107-1109: Verify the generic -compliance pattern doesn't over-match unintended jobs.

The -compliance pattern on line 1109 uses substring matching and will categorize any job containing "compliance" (e.g., "pre-compliance-check", "non-compliance-test") under lp-interop-compliance. While the pattern order is correct—more specific patterns (-complianceascode-, -compliance-destructive) are checked first—confirm that no unintended compliance-related jobs are being routed to this product. If broader matching is undesired, consider anchoring the pattern with additional delimiters (e.g., compliance- instead of just compliance).

@openshift-ci-robot
Copy link

Scheduling required tests:
/test e2e

@xiaojiey xiaojiey changed the title Add Component Readiness dashboard for Compliance Operator CMP-3987: Add Component Readiness dashboard for Compliance Operator Dec 2, 2025
@openshift-ci-robot
Copy link

openshift-ci-robot commented Dec 2, 2025

@xiaojiey: This pull request references CMP-3987 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.21.0" version, but no target version was set.

Details

In response to this:

Add Component Readiness dashboard for Compliance Operator:

  • For upstream test jobs, the job name is like: periodic-ci-ComplianceAsCode-content-master-4.18-e2e-aws-openshift-node-compliance-arm-weekly
  • For downstream test jobs, the job name is like periodic-ci-openshift-openshift-tests-private-release-4.12-amd64-nightly-aws-ipi-proxy-fips-f60-compliance or periodic-ci-openshift-openshift-tests-private-release-4.12-amd64-nightly-aws-ipi-proxy-fips-f60-compliance-destructive:

Summary by CodeRabbit

  • New Features
  • Added compliance-component-readiness analysis pathway with configurable release windows, advanced metrics, and variant options for comprehensive readiness assessment.
  • Introduced new compliance test suite to expand testing capabilities across compliance scenarios.
  • Consolidated compliance-related jobs under unified compliance product classification for streamlined tracking and analysis.

✏️ Tip: You can customize this high-level summary in your review settings.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

@openshift-ci-robot openshift-ci-robot added the jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. label Dec 2, 2025
@openshift-ci-robot
Copy link

openshift-ci-robot commented Dec 2, 2025

@xiaojiey: This pull request references CMP-3987 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.21.0" version, but no target version was set.

Details

In response to this:

Add Component Readiness dashboard for Compliance Operator:

  • For upstream test jobs, the job pattern is "-ComplianceAsCode-". The job name is like: periodic-ci-ComplianceAsCode-content-master-4.18-e2e-aws-openshift-node-compliance-arm-weekly
  • For downstream test jobs, the job pattern is "-compliance" or "-compliance-destructive". The job name is like periodic-ci-openshift-openshift-tests-private-release-4.12-amd64-nightly-aws-ipi-proxy-fips-f60-compliance or periodic-ci-openshift-openshift-tests-private-release-4.12-amd64-nightly-aws-ipi-proxy-fips-f60-compliance-destructive:

Summary by CodeRabbit

  • New Features
  • Added compliance-component-readiness analysis pathway with configurable release windows, advanced metrics, and variant options for comprehensive readiness assessment.
  • Introduced new compliance test suite to expand testing capabilities across compliance scenarios.
  • Consolidated compliance-related jobs under unified compliance product classification for streamlined tracking and analysis.

✏️ Tip: You can customize this high-level summary in your review settings.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

@xiaojiey xiaojiey force-pushed the compliance-dashboard branch from d1bdd22 to d8e9a70 Compare December 15, 2025 01:42
@openshift-ci-robot
Copy link

openshift-ci-robot commented Dec 15, 2025

@xiaojiey: This pull request references CMP-3987 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.22.0" version, but no target version was set.

Details

In response to this:

Add Component Readiness dashboard for Compliance Operator:

  • For upstream test jobs, the job pattern is "-ComplianceAsCode-". The job name is like: periodic-ci-ComplianceAsCode-content-master-4.18-e2e-aws-openshift-node-compliance-arm-weekly
  • For downstream test jobs, the job pattern is "-compliance" or "-compliance-destructive". The job name is like periodic-ci-openshift-openshift-tests-private-release-4.12-amd64-nightly-aws-ipi-proxy-fips-f60-compliance or periodic-ci-openshift-openshift-tests-private-release-4.12-amd64-nightly-aws-ipi-proxy-fips-f60-compliance-destructive:

Summary by CodeRabbit

  • New Features

  • Added multiple compliance readiness blocks with individual release windows, variant selections, metrics, and sampling options for separate analyses.

  • Added a new compliance test suite to be created/populated during test population.

  • Chores

  • Consolidated numerous compliance-related jobs under a unified compliance product classification for consistent tracking.

✏️ Tip: You can customize this high-level summary in your review settings.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

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

Actionable comments posted: 1

♻️ Duplicate comments (6)
config/views.yaml (6)

1743-1786: Missing JobTier filter may include unstable jobs.

This compliance view block lacks a JobTier filter in include_variants, which means it will include jobs of all tiers (blocking, informing, standard, candidate, hidden). This is the same concern previously raised in past review comments.

For consistency with main release views (e.g., 4.21-main at lines 39-42) and to ensure only stable jobs are tracked, consider adding:

       include_variants:
         Architecture:
           - amd64
           - arm64
+        JobTier:
+          - blocking
+          - informing
+          - standard
         LayeredProduct:
           - lp-interop-compliance
         Owner:
           - eng
         Platform:
           - azure
           - gcp
           - aws

Note: If downstream QE jobs default to JobTier: hidden (as mentioned in the Owner filter concern), you may need to either include hidden in the filter or opt-in specific compliance QE jobs to a different tier in pkg/variantregistry/ocp.go.


1787-1830: Missing JobTier filter may include unstable jobs.

Same issue as the 4.21 block - this view lacks a JobTier filter and may include unstable candidate or hidden jobs.


1831-1874: Missing JobTier filter may include unstable jobs.

Same issue as the 4.21 and 4.20 blocks - this view lacks a JobTier filter.


1875-1918: Missing JobTier filter may include unstable jobs.

Same issue as other compliance blocks - this view lacks a JobTier filter.


1919-1962: Missing JobTier filter may include unstable jobs.

Same issue as other compliance blocks - this view lacks a JobTier filter.


1963-2006: Missing JobTier filter may include unstable jobs.

Same issue as other compliance blocks - this view lacks a JobTier filter.

📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Cache: Disabled due to data retention organization setting

Knowledge base: Disabled due to data retention organization setting

📥 Commits

Reviewing files that changed from the base of the PR and between d1bdd22 and d8e9a70.

📒 Files selected for processing (3)
  • config/views.yaml (1 hunks)
  • pkg/db/suites.go (1 hunks)
  • pkg/variantregistry/ocp.go (1 hunks)
🔇 Additional comments (1)
pkg/db/suites.go (1)

71-71: LGTM!

The new test suite "Compliance-lp-interop" is correctly added to the testSuites list, following the established pattern for other layered product interop suites.

@openshift-ci-robot
Copy link

openshift-ci-robot commented Dec 15, 2025

@xiaojiey: This pull request references CMP-3987 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.22.0" version, but no target version was set.

Details

In response to this:

Add Component Readiness dashboard for Compliance Operator:

  • For upstream test jobs, the job pattern is "-ComplianceAsCode-". The job name is like: periodic-ci-ComplianceAsCode-content-master-4.18-e2e-aws-openshift-node-compliance-arm-weekly
  • For downstream test jobs, the job pattern is "-compliance" or "-compliance-destructive". The job name is like periodic-ci-openshift-openshift-tests-private-release-4.12-amd64-nightly-aws-ipi-proxy-fips-f60-compliance or periodic-ci-openshift-openshift-tests-private-release-4.12-amd64-nightly-aws-ipi-proxy-fips-f60-compliance-destructive:

Summary by CodeRabbit

  • New Features

  • Added multiple compliance readiness blocks with distinct release windows, variant selections, metrics, regression tracking, and sampling for separate analyses.

  • Added a new compliance test suite to be created/populated during test population.

  • Chores

  • Consolidated numerous compliance-related jobs under a unified compliance product classification for consistent tracking.

✏️ Tip: You can customize this high-level summary in your review settings.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

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

Actionable comments posted: 1

♻️ Duplicate comments (1)
config/views.yaml (1)

1743-2012: Add JobTier filter to compliance-readiness blocks to exclude unstable job tiers.

All six new lp-interop-compliance blocks (4.21 through 4.16) are missing a JobTier filter in their include_variants sections. Without this filter, the views may include candidate or hidden jobs that are not stable enough for component readiness tracking. This mirrors the concern raised in the previous review.

Apply this diff to add JobTier filtering to each block (example shown for 4.21-lp-interop-compliance; repeat for all six):

       include_variants:
         Architecture:
           - amd64
           - arm64
         LayeredProduct:
           - lp-interop-compliance
+        JobTier:
+          - blocking
+          - informing
+          - standard
         Owner:
           - eng
           - qe
         Platform:
           - azure
           - gcp
           - aws
📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Cache: Disabled due to data retention organization setting

Knowledge base: Disabled due to data retention organization setting

📥 Commits

Reviewing files that changed from the base of the PR and between d8e9a70 and b682638.

📒 Files selected for processing (2)
  • config/views.yaml (1 hunks)
  • pkg/variantregistry/snapshot.yaml (66 hunks)

@xiaojiey xiaojiey force-pushed the compliance-dashboard branch from b682638 to dd3edd0 Compare December 15, 2025 02:17
@openshift-ci-robot
Copy link

openshift-ci-robot commented Dec 15, 2025

@xiaojiey: This pull request references CMP-3987 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.22.0" version, but no target version was set.

Details

In response to this:

Add Component Readiness dashboard for Compliance Operator:

  • For upstream test jobs, the job pattern is "-ComplianceAsCode-". The job name is like: periodic-ci-ComplianceAsCode-content-master-4.18-e2e-aws-openshift-node-compliance-arm-weekly
  • For downstream test jobs, the job pattern is "-compliance" or "-compliance-destructive". The job name is like periodic-ci-openshift-openshift-tests-private-release-4.12-amd64-nightly-aws-ipi-proxy-fips-f60-compliance or periodic-ci-openshift-openshift-tests-private-release-4.12-amd64-nightly-aws-ipi-proxy-fips-f60-compliance-destructive:

Summary by CodeRabbit

  • New Features

  • Added multiple compliance readiness blocks covering several release windows with standardized variant selections, metrics, regression tracking, sampling, and multi-release analyses.

  • Added a new compliance test suite to be created/populated during test population.

  • Chores

  • Consolidated numerous compliance-related jobs under a unified compliance product classification for consistent tracking.

✏️ Tip: You can customize this high-level summary in your review settings.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

@openshift-ci-robot
Copy link

openshift-ci-robot commented Dec 15, 2025

@xiaojiey: This pull request references CMP-3987 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.22.0" version, but no target version was set.

Details

In response to this:

Overview

  1. This PR adds support for tracking Component Readiness for the Compliance Operator as a separate layered product dashboard. The Compliance Operator includes both upstream (ComplianceAsCode) and downstream testing, and we need dedicated dashboards to track readiness across these components.

  2. Component Readiness views are added for Compliance across actively supported OCP versions (4.16-4.21).

Changes

  1. Configuration Views (config/views.yaml)

Added Component Readiness views for Compliance across OCP versions:

  • 4.21-lp-Interop-compliance: Compares 4.21 vs 4.20
  • 4.20-lp-Interop-compliance: Compares 4.20 vs 4.19
  • 4.19-lp-Interop-compliance: Compares 4.19 vs 4.18
  • 4.18-lp-Interop-compliance: Compares 4.18 vs 4.17
  • 4.17-lp-Interop-compliance: Compares 4.17 vs 4.16
  • 4.16-lp-Interop-compliance: Compares 4.16 vs 4.15
  1. All views are configured with:
  • LayeredProduct filter: lp-interop-compliance
  • Platforms: azure, gcp, aws
  • Architectures: amd64, arm64
  • Owners: eng, qe
  • Metrics and regression tracking: enabled
  • Base releases use ga-30d to ga for GA'd releases
  1. Suite Registration (pkg/db/suites.go)
  • Added Compliance-lp-interop to the test suites list
  1. Variant Registry (pkg/variantregistry/ocp.go)
  • Added mapping rules for compliance jobs tagged as LayeredProduct lp-interop-compliance:
    • Jobs containing -complianceascode- (upstream tests)
    • Jobs containing -compliance-destructive (downstream destructive tests)
    • Jobs containing -compliance (downstream tests)
  1. Snapshot (pkg/variantregistry/snapshot.yaml)
  • Updated 66 compliance job entries to use LayeredProduct: lp-interop-compliance

Related Jobs

This tracks the following Compliance periodic jobs:

Upstream (ComplianceAsCode) Jobs:

  • periodic-ci-ComplianceAsCode-content-master-{version}-e2e-aws-openshift-node-compliance (amd64/arm64)
  • periodic-ci-ComplianceAsCode-content-master-{version}-e2e-aws-openshift-platform-compliance (amd64/arm64)

Downstream Jobs:

  • periodic-ci-openshift-openshift-tests-private-release-{version}-{arch}-nightly-{platform}-*-compliance
  • periodic-ci-openshift-openshift-tests-private-release-{version}-{arch}-nightly-{platform}-*-compliance-destructive

Coverage includes versions 4.12-4.21 across amd64, arm64, and multi architectures on platforms: aws, azure, gcp, baremetal, vsphere.

  1. Testing
  • Views follow the established naming pattern: {OCP_RELEASE}-lp-Interop-{product}
  • Configuration aligns with other LP-Interop views (CNV, Quay, ServiceMesh, COO, etc.)
  • Metrics and regression tracking enabled for proactive monitoring
  • Both engineering and QE owned jobs are included for comprehensive coverage

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

@openshift-ci-robot
Copy link

openshift-ci-robot commented Dec 15, 2025

@xiaojiey: This pull request references CMP-3987 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.22.0" version, but no target version was set.

Details

In response to this:

Overview

  1. This PR adds support for tracking Component Readiness for the Compliance Operator as a separate layered product dashboard. The Compliance Operator includes both upstream (ComplianceAsCode) and downstream testing, and we need dedicated dashboards to track readiness across these components.

  2. Component Readiness views are added for Compliance across actively supported OCP versions (4.16-4.21).

Changes

  1. Configuration Views (config/views.yaml)

Added Component Readiness views for Compliance across OCP versions:

  • 4.21-lp-Interop-compliance: Compares 4.21 vs 4.20
  • 4.20-lp-Interop-compliance: Compares 4.20 vs 4.19
  • 4.19-lp-Interop-compliance: Compares 4.19 vs 4.18
  • 4.18-lp-Interop-compliance: Compares 4.18 vs 4.17
  • 4.17-lp-Interop-compliance: Compares 4.17 vs 4.16
  • 4.16-lp-Interop-compliance: Compares 4.16 vs 4.15
  1. All views are configured with:
  • LayeredProduct filter: lp-interop-compliance
  • Platforms: azure, gcp, aws
  • Architectures: amd64, arm64
  • Owners: eng, qe
  • Metrics and regression tracking: enabled
  • Base releases use ga-30d to ga for GA'd releases
  1. Suite Registration (pkg/db/suites.go)
  • Added Compliance-lp-interop to the test suites list
  1. Variant Registry (pkg/variantregistry/ocp.go)
  • Added mapping rules for compliance jobs tagged as LayeredProduct lp-interop-compliance:
    • Jobs containing -complianceascode- (upstream tests)
    • Jobs containing -compliance-destructive (downstream destructive tests)
    • Jobs containing -compliance (downstream tests)
  1. Snapshot (pkg/variantregistry/snapshot.yaml)
  • Updated 66 compliance job entries to use LayeredProduct: lp-interop-compliance

Related Jobs

This tracks the following Compliance periodic jobs:

Upstream (ComplianceAsCode) Jobs:

  • periodic-ci-ComplianceAsCode-content-master-{version}-e2e-aws-openshift-node-compliance (amd64/arm64)
  • periodic-ci-ComplianceAsCode-content-master-{version}-e2e-aws-openshift-platform-compliance (amd64/arm64)

Downstream Jobs:

  • periodic-ci-openshift-openshift-tests-private-release-{version}-{arch}-nightly-{platform}-*-compliance
  • periodic-ci-openshift-openshift-tests-private-release-{version}-{arch}-nightly-{platform}-*-compliance-destructive

Coverage includes versions 4.12-4.21 across amd64, arm64, and multi architectures on platforms: aws, azure, gcp, baremetal, vsphere.

  1. Testing
  • Views follow the established naming pattern: {OCP_RELEASE}-lp-Interop-{product}
  • Configuration aligns with other LP-Interop views (CNV, Quay, ServiceMesh, COO, etc.)
  • Metrics and regression tracking enabled for proactive monitoring
  • Both engineering and QE owned jobs are included for comprehensive coverage

Summary by CodeRabbit

  • New Features

  • Added URL validation for artifact and job run links to improve safety when opening external resources.

  • Extended component readiness analysis with new compliance-tracking blocks for multiple release versions.

  • Chores

  • Updated product mapping configuration for compliance-related jobs.

  • Enhanced messaging formatting in analysis prompts.

  • Expanded test suite configuration.

✏️ Tip: You can customize this high-level summary in your review settings.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

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

Actionable comments posted: 0

🧹 Nitpick comments (1)
sippy-ng/src/component_readiness/JobArtifactQuery.js (1)

594-601: Align validateURL implementations to avoid subtle divergence

You now have three validateURL implementations: two with try/catch (Lines 594-601, 804-811) and one without (Lines 624-630). To keep behavior consistent and avoid future drift, consider giving the JAQResultTable version the same try/catch semantics (or extracting a shared helper in this file if Snyk still accepts it). This keeps all URL checks robust against malformed input while preserving the http/https protocol restriction.

Also applies to: 624-630, 804-811

📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Cache: Disabled due to data retention organization setting

Knowledge base: Disabled due to data retention organization setting

📥 Commits

Reviewing files that changed from the base of the PR and between dd3edd0 and d9b5bd5.

📒 Files selected for processing (2)
  • chat/prompts/payload-analysis.yaml (1 hunks)
  • sippy-ng/src/component_readiness/JobArtifactQuery.js (2 hunks)
🧰 Additional context used
🧬 Code graph analysis (1)
sippy-ng/src/component_readiness/JobArtifactQuery.js (1)
sippy-ng/src/helpers.js (1)
  • url (338-338)
🔇 Additional comments (2)
chat/prompts/payload-analysis.yaml (1)

106-112: Revert text formatting change looks good

Switching the high-confidence revert notice to "** REVERT RECOMMENDED **" keeps the instruction explicit while avoiding emoji; no behavioral impact on the workflow.

sippy-ng/src/component_readiness/JobArtifactQuery.js (1)

594-601: URL validation around window.open is correctly tightened

The new validateURL helpers (Lines 594-601 and 804-811) and the guards around window.open (Lines 603-608 and 813-822) safely restrict navigation to http/https URLs and handle parse errors via try/catch. This meaningfully hardens these paths without changing intended behavior.

Also applies to: 603-608, 804-822

@xiaojiey xiaojiey force-pushed the compliance-dashboard branch from d9b5bd5 to 2d2365c Compare December 15, 2025 03:10
@openshift-ci-robot
Copy link

openshift-ci-robot commented Dec 15, 2025

@xiaojiey: This pull request references CMP-3987 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.22.0" version, but no target version was set.

Details

In response to this:

Overview

  1. This PR adds support for tracking Component Readiness for the Compliance Operator as a separate layered product dashboard. The Compliance Operator includes both upstream (ComplianceAsCode) and downstream testing, and we need dedicated dashboards to track readiness across these components.

  2. Component Readiness views are added for Compliance across actively supported OCP versions (4.16-4.21).

Changes

  1. Configuration Views (config/views.yaml)

Added Component Readiness views for Compliance across OCP versions:

  • 4.21-lp-Interop-compliance: Compares 4.21 vs 4.20
  • 4.20-lp-Interop-compliance: Compares 4.20 vs 4.19
  • 4.19-lp-Interop-compliance: Compares 4.19 vs 4.18
  • 4.18-lp-Interop-compliance: Compares 4.18 vs 4.17
  • 4.17-lp-Interop-compliance: Compares 4.17 vs 4.16
  • 4.16-lp-Interop-compliance: Compares 4.16 vs 4.15
  1. All views are configured with:
  • LayeredProduct filter: lp-interop-compliance
  • Platforms: azure, gcp, aws
  • Architectures: amd64, arm64
  • Owners: eng, qe
  • Metrics and regression tracking: enabled
  • Base releases use ga-30d to ga for GA'd releases
  1. Suite Registration (pkg/db/suites.go)
  • Added Compliance-lp-interop to the test suites list
  1. Variant Registry (pkg/variantregistry/ocp.go)
  • Added mapping rules for compliance jobs tagged as LayeredProduct lp-interop-compliance:
    • Jobs containing -complianceascode- (upstream tests)
    • Jobs containing -compliance-destructive (downstream destructive tests)
    • Jobs containing -compliance (downstream tests)
  1. Snapshot (pkg/variantregistry/snapshot.yaml)
  • Updated 66 compliance job entries to use LayeredProduct: lp-interop-compliance

Related Jobs

This tracks the following Compliance periodic jobs:

Upstream (ComplianceAsCode) Jobs:

  • periodic-ci-ComplianceAsCode-content-master-{version}-e2e-aws-openshift-node-compliance (amd64/arm64)
  • periodic-ci-ComplianceAsCode-content-master-{version}-e2e-aws-openshift-platform-compliance (amd64/arm64)

Downstream Jobs:

  • periodic-ci-openshift-openshift-tests-private-release-{version}-{arch}-nightly-{platform}-*-compliance
  • periodic-ci-openshift-openshift-tests-private-release-{version}-{arch}-nightly-{platform}-*-compliance-destructive

Coverage includes versions 4.12-4.21 across amd64, arm64, and multi architectures on platforms: aws, azure, gcp, baremetal, vsphere.

  1. Testing
  • Views follow the established naming pattern: {OCP_RELEASE}-lp-Interop-{product}
  • Configuration aligns with other LP-Interop views (CNV, Quay, ServiceMesh, COO, etc.)
  • Metrics and regression tracking enabled for proactive monitoring
  • Both engineering and QE owned jobs are included for comprehensive coverage

Summary by CodeRabbit

  • New Features
  • Added interoperability compliance testing coverage for releases 4.19, 4.20, and 4.21.
  • Introduced unified compliance job routing and classification to streamline test organization.

✏️ Tip: You can customize this high-level summary in your review settings.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

@xiaojiey
Copy link
Author

@neisw @deepsm007 Could you please help to review this PR, thanks.

@xiaojiey xiaojiey force-pushed the compliance-dashboard branch from 2d2365c to 7a16b9d Compare January 7, 2026 08:14
@openshift-merge-robot openshift-merge-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Jan 7, 2026
@openshift-ci-robot
Copy link

openshift-ci-robot commented Jan 7, 2026

@xiaojiey: This pull request references CMP-3987 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.22.0" version, but no target version was set.

Details

In response to this:

Overview

  1. This PR adds support for tracking Component Readiness for the Compliance Operator as a separate layered product dashboard. The Compliance Operator includes both upstream (ComplianceAsCode) and downstream testing, and we need dedicated dashboards to track readiness across these components.

  2. Component Readiness views are added for Compliance across actively supported OCP versions (4.16-4.21).

Changes

  1. Configuration Views (config/views.yaml)

Added Component Readiness views for Compliance across OCP versions:

  • 4.21-lp-Interop-compliance: Compares 4.21 vs 4.20
  • 4.20-lp-Interop-compliance: Compares 4.20 vs 4.19
  • 4.19-lp-Interop-compliance: Compares 4.19 vs 4.18
  • 4.18-lp-Interop-compliance: Compares 4.18 vs 4.17
  • 4.17-lp-Interop-compliance: Compares 4.17 vs 4.16
  • 4.16-lp-Interop-compliance: Compares 4.16 vs 4.15
  1. All views are configured with:
  • LayeredProduct filter: lp-interop-compliance
  • Platforms: azure, gcp, aws
  • Architectures: amd64, arm64
  • Owners: eng, qe
  • Metrics and regression tracking: enabled
  • Base releases use ga-30d to ga for GA'd releases
  1. Suite Registration (pkg/db/suites.go)
  • Added Compliance-lp-interop to the test suites list
  1. Variant Registry (pkg/variantregistry/ocp.go)
  • Added mapping rules for compliance jobs tagged as LayeredProduct lp-interop-compliance:
    • Jobs containing -complianceascode- (upstream tests)
    • Jobs containing -compliance-destructive (downstream destructive tests)
    • Jobs containing -compliance (downstream tests)
  1. Snapshot (pkg/variantregistry/snapshot.yaml)
  • Updated 66 compliance job entries to use LayeredProduct: lp-interop-compliance

Related Jobs

This tracks the following Compliance periodic jobs:

Upstream (ComplianceAsCode) Jobs:

  • periodic-ci-ComplianceAsCode-content-master-{version}-e2e-aws-openshift-node-compliance (amd64/arm64)
  • periodic-ci-ComplianceAsCode-content-master-{version}-e2e-aws-openshift-platform-compliance (amd64/arm64)

Downstream Jobs:

  • periodic-ci-openshift-openshift-tests-private-release-{version}-{arch}-nightly-{platform}-*-compliance
  • periodic-ci-openshift-openshift-tests-private-release-{version}-{arch}-nightly-{platform}-*-compliance-destructive

Coverage includes versions 4.12-4.21 across amd64, arm64, and multi architectures on platforms: aws, azure, gcp, baremetal, vsphere.

  1. Testing
  • Views follow the established naming pattern: {OCP_RELEASE}-lp-Interop-{product}
  • Configuration aligns with other LP-Interop views (CNV, Quay, ServiceMesh, COO, etc.)
  • Metrics and regression tracking enabled for proactive monitoring
  • Both engineering and QE owned jobs are included for comprehensive coverage

Summary by CodeRabbit

  • New Features

  • Expanded interoperability compliance testing coverage across releases 4.16–4.21.

  • Added a dedicated compliance test suite to include these new variants.

  • Tests

  • Periodic CI jobs updated to classify and route compliance-related workloads under the unified compliance category.

✏️ Tip: You can customize this high-level summary in your review settings.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

@xiaojiey xiaojiey force-pushed the compliance-dashboard branch from 7a16b9d to 6d5a4e4 Compare January 7, 2026 08:21
@openshift-merge-robot openshift-merge-robot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Jan 7, 2026
@openshift-ci-robot
Copy link

openshift-ci-robot commented Jan 7, 2026

@xiaojiey: This pull request references CMP-3987 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.22.0" version, but no target version was set.

Details

In response to this:

Overview

  1. This PR adds support for tracking Component Readiness for the Compliance Operator as a separate layered product dashboard. The Compliance Operator includes both upstream (ComplianceAsCode) and downstream testing, and we need dedicated dashboards to track readiness across these components.

  2. Component Readiness views are added for Compliance across actively supported OCP versions (4.16-4.21).

Changes

  1. Configuration Views (config/views.yaml)

Added Component Readiness views for Compliance across OCP versions:

  • 4.21-lp-Interop-compliance: Compares 4.21 vs 4.20
  • 4.20-lp-Interop-compliance: Compares 4.20 vs 4.19
  • 4.19-lp-Interop-compliance: Compares 4.19 vs 4.18
  • 4.18-lp-Interop-compliance: Compares 4.18 vs 4.17
  • 4.17-lp-Interop-compliance: Compares 4.17 vs 4.16
  • 4.16-lp-Interop-compliance: Compares 4.16 vs 4.15
  1. All views are configured with:
  • LayeredProduct filter: lp-interop-compliance
  • Platforms: azure, gcp, aws
  • Architectures: amd64, arm64
  • Owners: eng, qe
  • Metrics and regression tracking: enabled
  • Base releases use ga-30d to ga for GA'd releases
  1. Suite Registration (pkg/db/suites.go)
  • Added Compliance-lp-interop to the test suites list
  1. Variant Registry (pkg/variantregistry/ocp.go)
  • Added mapping rules for compliance jobs tagged as LayeredProduct lp-interop-compliance:
    • Jobs containing -complianceascode- (upstream tests)
    • Jobs containing -compliance-destructive (downstream destructive tests)
    • Jobs containing -compliance (downstream tests)
  1. Snapshot (pkg/variantregistry/snapshot.yaml)
  • Updated 66 compliance job entries to use LayeredProduct: lp-interop-compliance

Related Jobs

This tracks the following Compliance periodic jobs:

Upstream (ComplianceAsCode) Jobs:

  • periodic-ci-ComplianceAsCode-content-master-{version}-e2e-aws-openshift-node-compliance (amd64/arm64)
  • periodic-ci-ComplianceAsCode-content-master-{version}-e2e-aws-openshift-platform-compliance (amd64/arm64)

Downstream Jobs:

  • periodic-ci-openshift-openshift-tests-private-release-{version}-{arch}-nightly-{platform}-*-compliance
  • periodic-ci-openshift-openshift-tests-private-release-{version}-{arch}-nightly-{platform}-*-compliance-destructive

Coverage includes versions 4.12-4.21 across amd64, arm64, and multi architectures on platforms: aws, azure, gcp, baremetal, vsphere.

  1. Testing
  • Views follow the established naming pattern: {OCP_RELEASE}-lp-Interop-{product}
  • Configuration aligns with other LP-Interop views (CNV, Quay, ServiceMesh, COO, etc.)
  • Metrics and regression tracking enabled for proactive monitoring
  • Both engineering and QE owned jobs are included for comprehensive coverage

Summary by CodeRabbit

  • New Features

  • Expanded interoperability compliance coverage across releases 4.16–4.21 with many new readiness variants and comparison options.

  • Unified compliance grouping so related compliance workloads are classified together.

  • Tests

  • Added a dedicated compliance test suite to include the new variants.

  • Periodic CI job metadata updated to route jobs under the unified compliance category.

  • Chores

  • Merged and reconciled configuration updates to expose the new variants.

✏️ Tip: You can customize this high-level summary in your review settings.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

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

Actionable comments posted: 2

🤖 Fix all issues with AI agents
In @config/views.yaml:
- Around line 2922-2923: Resolve the merge conflict by setting
regression_tracking.enabled to false for the COO views listed: update the
entries for 4.19-lp-Interop-coo, 4.18-lp-Interop-coo, 4.17-lp-Interop-coo, and
4.16-lp-Interop-coo so that each has regression_tracking: enabled: false
(replace the conflicting true values from the feature branch), ensure the final
YAML contains only the false value for those view blocks, and remove any
leftover conflict markers.
- Line 1678: The file contains unresolved Git conflict markers ("<<<<<<< HEAD",
"=======", ">>>>>>> 7a16b9d6") that break YAML parsing; rebase onto main,
resolve the conflict by selecting or merging the intended changes between the
two versions (remove the conflict markers and keep the correct YAML nodes),
commit the resolved content, and validate the file with a YAML linter to ensure
no syntax errors remain.
📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Cache: Disabled due to data retention organization setting

Knowledge base: Disabled due to data retention organization setting

📥 Commits

Reviewing files that changed from the base of the PR and between 7a16b9d and 6d5a4e4.

📒 Files selected for processing (1)
  • config/views.yaml

@xiaojiey xiaojiey force-pushed the compliance-dashboard branch from 6d5a4e4 to 10cea42 Compare January 7, 2026 08:39
@openshift-ci-robot
Copy link

openshift-ci-robot commented Jan 7, 2026

@xiaojiey: This pull request references CMP-3987 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.22.0" version, but no target version was set.

Details

In response to this:

Overview

  1. This PR adds support for tracking Component Readiness for the Compliance Operator as a separate layered product dashboard. The Compliance Operator includes both upstream (ComplianceAsCode) and downstream testing, and we need dedicated dashboards to track readiness across these components.

  2. Component Readiness views are added for Compliance across actively supported OCP versions (4.16-4.21).

Changes

  1. Configuration Views (config/views.yaml)

Added Component Readiness views for Compliance across OCP versions:

  • 4.21-lp-Interop-compliance: Compares 4.21 vs 4.20
  • 4.20-lp-Interop-compliance: Compares 4.20 vs 4.19
  • 4.19-lp-Interop-compliance: Compares 4.19 vs 4.18
  • 4.18-lp-Interop-compliance: Compares 4.18 vs 4.17
  • 4.17-lp-Interop-compliance: Compares 4.17 vs 4.16
  • 4.16-lp-Interop-compliance: Compares 4.16 vs 4.15
  1. All views are configured with:
  • LayeredProduct filter: lp-interop-compliance
  • Platforms: azure, gcp, aws
  • Architectures: amd64, arm64
  • Owners: eng, qe
  • Metrics and regression tracking: enabled
  • Base releases use ga-30d to ga for GA'd releases
  1. Suite Registration (pkg/db/suites.go)
  • Added Compliance-lp-interop to the test suites list
  1. Variant Registry (pkg/variantregistry/ocp.go)
  • Added mapping rules for compliance jobs tagged as LayeredProduct lp-interop-compliance:
    • Jobs containing -complianceascode- (upstream tests)
    • Jobs containing -compliance-destructive (downstream destructive tests)
    • Jobs containing -compliance (downstream tests)
  1. Snapshot (pkg/variantregistry/snapshot.yaml)
  • Updated 66 compliance job entries to use LayeredProduct: lp-interop-compliance

Related Jobs

This tracks the following Compliance periodic jobs:

Upstream (ComplianceAsCode) Jobs:

  • periodic-ci-ComplianceAsCode-content-master-{version}-e2e-aws-openshift-node-compliance (amd64/arm64)
  • periodic-ci-ComplianceAsCode-content-master-{version}-e2e-aws-openshift-platform-compliance (amd64/arm64)

Downstream Jobs:

  • periodic-ci-openshift-openshift-tests-private-release-{version}-{arch}-nightly-{platform}-*-compliance
  • periodic-ci-openshift-openshift-tests-private-release-{version}-{arch}-nightly-{platform}-*-compliance-destructive

Coverage includes versions 4.12-4.21 across amd64, arm64, and multi architectures on platforms: aws, azure, gcp, baremetal, vsphere.

  1. Testing
  • Views follow the established naming pattern: {OCP_RELEASE}-lp-Interop-{product}
  • Configuration aligns with other LP-Interop views (CNV, Quay, ServiceMesh, COO, etc.)
  • Metrics and regression tracking enabled for proactive monitoring
  • Both engineering and QE owned jobs are included for comprehensive coverage

Summary by CodeRabbit

  • New Features

  • Introduced a richer, multi-release readiness schema with many new variant dimensions and cross-variant comparison options.

  • Added multi-release analysis, layered-product compliance grouping, and finer controls for test partitioning and metrics.

  • Tests

  • Added a dedicated compliance test suite to cover the new variants.

  • Periodic CI job metadata updated to route jobs under the unified compliance category.

  • Chores

  • Consolidated and expanded configuration blocks to expose the new variants and options.

✏️ Tip: You can customize this high-level summary in your review settings.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

@xiaojiey xiaojiey force-pushed the compliance-dashboard branch from 10cea42 to a8d66f2 Compare January 7, 2026 08:46
Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

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

Actionable comments posted: 1

🤖 Fix all issues with AI agents
In @config/views.yaml:
- Around line 1677-1679: The YAML comment is indented too far and causes a
parsing error; move the comment so it aligns with the surrounding keys (same
indentation level as relative_start and relative_end) or remove it entirely;
update the comment line that currently precedes relative_start so its leading
spaces match the keys in this block (referencing the keys relative_start and
relative_end) to fix the YAML syntax.
🧹 Nitpick comments (1)
config/views.yaml (1)

2250-2261: Consider adding JobTier filter to ensure job stability.

The compliance views don't specify a JobTier filter in include_variants, unlike standard views (e.g., lines 646-649 for 4.21-main). Without this filter, the views will include jobs of all tiers, potentially including candidate or hidden jobs that may not be stable enough for component readiness tracking.

♻️ Suggested addition
       include_variants:
         Architecture:
           - amd64
           - arm64
+        JobTier:
+          - blocking
+          - informing
+          - standard
         LayeredProduct:
           - lp-interop-compliance

Apply this same pattern to all six compliance view blocks (4.21, 4.20, 4.19, 4.18, 4.17, 4.16).

📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Cache: Disabled due to data retention organization setting

Knowledge base: Disabled due to data retention organization setting

📥 Commits

Reviewing files that changed from the base of the PR and between 6d5a4e4 and 10cea42.

📒 Files selected for processing (4)
  • config/views.yaml
  • pkg/db/suites.go
  • pkg/variantregistry/ocp.go
  • pkg/variantregistry/snapshot.yaml
🧰 Additional context used
🪛 YAMLlint (1.37.1)
config/views.yaml

[error] 1678-1678: syntax error: expected , but found ''

(syntax)

🔇 Additional comments (3)
pkg/db/suites.go (1)

72-72: LGTM! Test suite addition aligns with compliance operator support.

The new "Compliance-lp-interop" test suite follows the established naming convention for lp-interop suites and integrates correctly with the LayeredProduct mappings added in pkg/variantregistry/ocp.go.

pkg/variantregistry/ocp.go (1)

1111-1113: LGTM! Compliance job mappings follow the established pattern.

The three new LayeredProduct mappings correctly route compliance-related jobs to lp-interop-compliance. The ordering is appropriate, with specific patterns (-complianceascode-, -compliance-destructive) checked before the broader -compliance pattern. This ensures precise matching for specialized compliance jobs while catching all other compliance jobs with the general pattern.

config/views.yaml (1)

2232-2501: Compliance view configurations are well-structured and address previous feedback.

The six compliance view blocks (4.21, 4.20, 4.19, 4.18, 4.17, 4.16) correctly include both eng and qe in the Owner filter, addressing the past review concern about downstream QE-owned compliance jobs. The regression_tracking: enabled: false setting aligns with reviewer guidance. The view structure is consistent with other LP-Interop views.

@openshift-ci-robot
Copy link

openshift-ci-robot commented Jan 7, 2026

@xiaojiey: This pull request references CMP-3987 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.22.0" version, but no target version was set.

Details

In response to this:

Overview

  1. This PR adds support for tracking Component Readiness for the Compliance Operator as a separate layered product dashboard. The Compliance Operator includes both upstream (ComplianceAsCode) and downstream testing, and we need dedicated dashboards to track readiness across these components.

  2. Component Readiness views are added for Compliance across actively supported OCP versions (4.16-4.21).

Changes

  1. Configuration Views (config/views.yaml)

Added Component Readiness views for Compliance across OCP versions:

  • 4.21-lp-Interop-compliance: Compares 4.21 vs 4.20
  • 4.20-lp-Interop-compliance: Compares 4.20 vs 4.19
  • 4.19-lp-Interop-compliance: Compares 4.19 vs 4.18
  • 4.18-lp-Interop-compliance: Compares 4.18 vs 4.17
  • 4.17-lp-Interop-compliance: Compares 4.17 vs 4.16
  • 4.16-lp-Interop-compliance: Compares 4.16 vs 4.15
  1. All views are configured with:
  • LayeredProduct filter: lp-interop-compliance
  • Platforms: azure, gcp, aws
  • Architectures: amd64, arm64
  • Owners: eng, qe
  • Metrics and regression tracking: enabled
  • Base releases use ga-30d to ga for GA'd releases
  1. Suite Registration (pkg/db/suites.go)
  • Added Compliance-lp-interop to the test suites list
  1. Variant Registry (pkg/variantregistry/ocp.go)
  • Added mapping rules for compliance jobs tagged as LayeredProduct lp-interop-compliance:
    • Jobs containing -complianceascode- (upstream tests)
    • Jobs containing -compliance-destructive (downstream destructive tests)
    • Jobs containing -compliance (downstream tests)
  1. Snapshot (pkg/variantregistry/snapshot.yaml)
  • Updated 66 compliance job entries to use LayeredProduct: lp-interop-compliance

Related Jobs

This tracks the following Compliance periodic jobs:

Upstream (ComplianceAsCode) Jobs:

  • periodic-ci-ComplianceAsCode-content-master-{version}-e2e-aws-openshift-node-compliance (amd64/arm64)
  • periodic-ci-ComplianceAsCode-content-master-{version}-e2e-aws-openshift-platform-compliance (amd64/arm64)

Downstream Jobs:

  • periodic-ci-openshift-openshift-tests-private-release-{version}-{arch}-nightly-{platform}-*-compliance
  • periodic-ci-openshift-openshift-tests-private-release-{version}-{arch}-nightly-{platform}-*-compliance-destructive

Coverage includes versions 4.12-4.21 across amd64, arm64, and multi architectures on platforms: aws, azure, gcp, baremetal, vsphere.

  1. Testing
  • Views follow the established naming pattern: {OCP_RELEASE}-lp-Interop-{product}
  • Configuration aligns with other LP-Interop views (CNV, Quay, ServiceMesh, COO, etc.)
  • Metrics and regression tracking enabled for proactive monitoring
  • Both engineering and QE owned jobs are included for comprehensive coverage

Summary by CodeRabbit

  • New Features

  • Expanded multi-release readiness coverage with additional interop/compliance-focused blocks and adjusted release time anchors.

  • Broader variant dimensions (architectures, platforms, layered-product variants, owners) for cross-release comparison.

  • Tests

  • Added a dedicated compliance test suite and routed periodic jobs into the unified compliance grouping.

  • Chores

  • Consolidated and expanded configuration blocks while preserving existing test gating and metric controls.

✏️ Tip: You can customize this high-level summary in your review settings.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

@xiaojiey xiaojiey force-pushed the compliance-dashboard branch from a8d66f2 to a84e3cf Compare January 7, 2026 09:35
@openshift-ci-robot
Copy link

openshift-ci-robot commented Jan 7, 2026

@xiaojiey: This pull request references CMP-3987 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.22.0" version, but no target version was set.

Details

In response to this:

Overview

  1. This PR adds support for tracking Component Readiness for the Compliance Operator as a separate layered product dashboard. The Compliance Operator includes both upstream (ComplianceAsCode) and downstream testing, and we need dedicated dashboards to track readiness across these components.

  2. Component Readiness views are added for Compliance across actively supported OCP versions (4.16-4.21).

Changes

  1. Configuration Views (config/views.yaml)

Added Component Readiness views for Compliance across OCP versions:

  • 4.21-lp-Interop-compliance: Compares 4.21 vs 4.20
  • 4.20-lp-Interop-compliance: Compares 4.20 vs 4.19
  • 4.19-lp-Interop-compliance: Compares 4.19 vs 4.18
  • 4.18-lp-Interop-compliance: Compares 4.18 vs 4.17
  • 4.17-lp-Interop-compliance: Compares 4.17 vs 4.16
  • 4.16-lp-Interop-compliance: Compares 4.16 vs 4.15
  1. All views are configured with:
  • LayeredProduct filter: lp-interop-compliance
  • Platforms: azure, gcp, aws
  • Architectures: amd64, arm64
  • Owners: eng, qe
  • Metrics and regression tracking: enabled
  • Base releases use ga-30d to ga for GA'd releases
  1. Suite Registration (pkg/db/suites.go)
  • Added Compliance-lp-interop to the test suites list
  1. Variant Registry (pkg/variantregistry/ocp.go)
  • Added mapping rules for compliance jobs tagged as LayeredProduct lp-interop-compliance:
    • Jobs containing -complianceascode- (upstream tests)
    • Jobs containing -compliance-destructive (downstream destructive tests)
    • Jobs containing -compliance (downstream tests)
  1. Snapshot (pkg/variantregistry/snapshot.yaml)
  • Updated 66 compliance job entries to use LayeredProduct: lp-interop-compliance

Related Jobs

This tracks the following Compliance periodic jobs:

Upstream (ComplianceAsCode) Jobs:

  • periodic-ci-ComplianceAsCode-content-master-{version}-e2e-aws-openshift-node-compliance (amd64/arm64)
  • periodic-ci-ComplianceAsCode-content-master-{version}-e2e-aws-openshift-platform-compliance (amd64/arm64)

Downstream Jobs:

  • periodic-ci-openshift-openshift-tests-private-release-{version}-{arch}-nightly-{platform}-*-compliance
  • periodic-ci-openshift-openshift-tests-private-release-{version}-{arch}-nightly-{platform}-*-compliance-destructive

Coverage includes versions 4.12-4.21 across amd64, arm64, and multi architectures on platforms: aws, azure, gcp, baremetal, vsphere.

  1. Testing
  • Views follow the established naming pattern: {OCP_RELEASE}-lp-Interop-{product}
  • Configuration aligns with other LP-Interop views (CNV, Quay, ServiceMesh, COO, etc.)
  • Metrics and regression tracking enabled for proactive monitoring
  • Both engineering and QE owned jobs are included for comprehensive coverage

Summary by CodeRabbit

  • New Features

  • Expanded multi-release readiness coverage with additional interop/compliance-focused blocks and adjusted release anchors.

  • Broader variant dimensions (architectures, platforms, layered-product variants, owners) for cross-release comparison.

  • Tests

  • Added a dedicated compliance test suite and routed periodic jobs into the unified compliance grouping.

  • Chores

  • Consolidated and standardized configuration entries and snapshot defaults for compliance-oriented variants.

✏️ Tip: You can customize this high-level summary in your review settings.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

@openshift-ci-robot
Copy link

Scheduling required tests:
/test e2e

enabled: false
prime_cache:
enabled: false
- name: 4.21-lp-Interop-compliance
Copy link
Contributor

Choose a reason for hiding this comment

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

Do you also want a 4.22 view now that we have branched?

@xiaojiey xiaojiey force-pushed the compliance-dashboard branch from a84e3cf to e26dbf3 Compare January 15, 2026 04:31
@openshift-ci-robot
Copy link

openshift-ci-robot commented Jan 15, 2026

@xiaojiey: This pull request references CMP-3987 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.22.0" version, but no target version was set.

Details

In response to this:

Overview

  1. This PR adds support for tracking Component Readiness for the Compliance Operator as a separate layered product dashboard. The Compliance Operator includes both upstream (ComplianceAsCode) and downstream testing, and we need dedicated dashboards to track readiness across these components.

  2. Component Readiness views are added for Compliance across actively supported OCP versions (4.16-4.21).

Changes

  1. Configuration Views (config/views.yaml)

Added Component Readiness views for Compliance across OCP versions:

  • 4.22-lp-Interop-compliance: Compares 4.22 vs 4.21
  • 4.21-lp-Interop-compliance: Compares 4.21 vs 4.20
  • 4.20-lp-Interop-compliance: Compares 4.20 vs 4.19
  • 4.19-lp-Interop-compliance: Compares 4.19 vs 4.18
  • 4.18-lp-Interop-compliance: Compares 4.18 vs 4.17
  • 4.17-lp-Interop-compliance: Compares 4.17 vs 4.16
  • 4.16-lp-Interop-compliance: Compares 4.16 vs 4.15
  1. All views are configured with:
  • LayeredProduct filter: lp-interop-compliance
  • Platforms: azure, gcp, aws
  • Architectures: amd64, arm64
  • Owners: eng, qe
  • Metrics and regression tracking: enabled
  • Base releases use ga-30d to ga for GA'd releases
  1. Suite Registration (pkg/db/suites.go)
  • Added Compliance-lp-interop to the test suites list
  1. Variant Registry (pkg/variantregistry/ocp.go)
  • Added mapping rules for compliance jobs tagged as LayeredProduct lp-interop-compliance:
    • Jobs containing -complianceascode- (upstream tests)
    • Jobs containing -compliance-destructive (downstream destructive tests)
    • Jobs containing -compliance (downstream tests)
  1. Snapshot (pkg/variantregistry/snapshot.yaml)
  • Updated 66 compliance job entries to use LayeredProduct: lp-interop-compliance

Related Jobs

This tracks the following Compliance periodic jobs:

Upstream (ComplianceAsCode) Jobs:

  • periodic-ci-ComplianceAsCode-content-master-{version}-e2e-aws-openshift-node-compliance (amd64/arm64)
  • periodic-ci-ComplianceAsCode-content-master-{version}-e2e-aws-openshift-platform-compliance (amd64/arm64)

Downstream Jobs:

  • periodic-ci-openshift-openshift-tests-private-release-{version}-{arch}-nightly-{platform}-*-compliance
  • periodic-ci-openshift-openshift-tests-private-release-{version}-{arch}-nightly-{platform}-*-compliance-destructive

Coverage includes versions 4.12-4.21 across amd64, arm64, and multi architectures on platforms: aws, azure, gcp, baremetal, vsphere.

  1. Testing
  • Views follow the established naming pattern: {OCP_RELEASE}-lp-Interop-{product}
  • Configuration aligns with other LP-Interop views (CNV, Quay, ServiceMesh, COO, etc.)
  • Metrics and regression tracking enabled for proactive monitoring
  • Both engineering and QE owned jobs are included for comprehensive coverage

Summary by CodeRabbit

  • New Features

  • Expanded multi-release readiness coverage with additional interop/compliance-focused blocks and adjusted release anchors.

  • Broader variant dimensions (architectures, platforms, layered-product variants, owners) for cross-release comparison.

  • Tests

  • Added a dedicated compliance test suite and routed periodic jobs into the unified compliance grouping.

  • Chores

  • Consolidated and standardized configuration entries and snapshot defaults for compliance-oriented variants.

✏️ Tip: You can customize this high-level summary in your review settings.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

@openshift-ci-robot
Copy link

openshift-ci-robot commented Jan 15, 2026

@xiaojiey: This pull request references CMP-3987 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.22.0" version, but no target version was set.

Details

In response to this:

Overview

  1. This PR adds support for tracking Component Readiness for the Compliance Operator as a separate layered product dashboard. The Compliance Operator includes both upstream (ComplianceAsCode) and downstream testing, and we need dedicated dashboards to track readiness across these components.

  2. Component Readiness views are added for Compliance across actively supported OCP versions (4.16-4.21).

Changes

  1. Configuration Views (config/views.yaml)

Added Component Readiness views for Compliance across OCP versions:

  • 4.22-lp-Interop-compliance: Compares 4.22 vs 4.21
  • 4.21-lp-Interop-compliance: Compares 4.21 vs 4.20
  • 4.20-lp-Interop-compliance: Compares 4.20 vs 4.19
  • 4.19-lp-Interop-compliance: Compares 4.19 vs 4.18
  • 4.18-lp-Interop-compliance: Compares 4.18 vs 4.17
  • 4.17-lp-Interop-compliance: Compares 4.17 vs 4.16
  • 4.16-lp-Interop-compliance: Compares 4.16 vs 4.15
  1. All views are configured with:
  • LayeredProduct filter: lp-interop-compliance
  • Platforms: azure, gcp, aws
  • Architectures: amd64, arm64
  • Owners: eng, qe
  • Metrics and regression tracking: enabled
  • Base releases use ga-30d to ga for GA'd releases
  1. Suite Registration (pkg/db/suites.go)
  • Added Compliance-lp-interop to the test suites list
  1. Variant Registry (pkg/variantregistry/ocp.go)
  • Added mapping rules for compliance jobs tagged as LayeredProduct lp-interop-compliance:
    • Jobs containing -complianceascode- (upstream tests)
    • Jobs containing -compliance-destructive (downstream destructive tests)
    • Jobs containing -compliance (downstream tests)
  1. Snapshot (pkg/variantregistry/snapshot.yaml)
  • Updated 66 compliance job entries to use LayeredProduct: lp-interop-compliance

Related Jobs

This tracks the following Compliance periodic jobs:

Upstream (ComplianceAsCode) Jobs:

  • periodic-ci-ComplianceAsCode-content-master-{version}-e2e-aws-openshift-node-compliance (amd64/arm64)
  • periodic-ci-ComplianceAsCode-content-master-{version}-e2e-aws-openshift-platform-compliance (amd64/arm64)

Downstream Jobs:

  • periodic-ci-openshift-openshift-tests-private-release-{version}-{arch}-nightly-{platform}-*-compliance
  • periodic-ci-openshift-openshift-tests-private-release-{version}-{arch}-nightly-{platform}-*-compliance-destructive

Coverage includes versions 4.12-4.21 across amd64, arm64, and multi architectures on platforms: aws, azure, gcp, baremetal, vsphere.

  1. Testing
  • Views follow the established naming pattern: {OCP_RELEASE}-lp-Interop-{product}
  • Configuration aligns with other LP-Interop views (CNV, Quay, ServiceMesh, COO, etc.)
  • Metrics and regression tracking enabled for proactive monitoring
  • Both engineering and QE owned jobs are included for comprehensive coverage

Summary by CodeRabbit

  • New Features

  • Expanded multi-release readiness coverage with additional interop/compliance releases and aligned release anchors.

  • Broader variant dimensions (architectures, platforms, layered-product variants, owners) for cross-release comparison.

  • Tests

  • Added a dedicated compliance test suite and routed periodic jobs into a unified compliance grouping.

  • Chores

  • Standardized configuration and snapshot defaults for compliance-oriented variants.

✏️ Tip: You can customize this high-level summary in your review settings.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

@xiaojiey xiaojiey force-pushed the compliance-dashboard branch from e26dbf3 to 8b8e36f Compare January 15, 2026 05:04
@openshift-ci-robot
Copy link

openshift-ci-robot commented Jan 15, 2026

@xiaojiey: This pull request references CMP-3987 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.22.0" version, but no target version was set.

Details

In response to this:

Overview

  1. This PR adds support for tracking Component Readiness for the Compliance Operator as a separate layered product dashboard. The Compliance Operator includes both upstream (ComplianceAsCode) and downstream testing, and we need dedicated dashboards to track readiness across these components.

  2. Component Readiness views are added for Compliance across actively supported OCP versions (4.16-4.21).

Changes

  1. Configuration Views (config/views.yaml)

Added Component Readiness views for Compliance across OCP versions:

  • 4.22-lp-Interop-compliance: Compares 4.22 vs 4.21
  • 4.21-lp-Interop-compliance: Compares 4.21 vs 4.20
  • 4.20-lp-Interop-compliance: Compares 4.20 vs 4.19
  • 4.19-lp-Interop-compliance: Compares 4.19 vs 4.18
  • 4.18-lp-Interop-compliance: Compares 4.18 vs 4.17
  • 4.17-lp-Interop-compliance: Compares 4.17 vs 4.16
  • 4.16-lp-Interop-compliance: Compares 4.16 vs 4.15
  1. All views are configured with:
  • LayeredProduct filter: lp-interop-compliance
  • Platforms: azure, gcp, aws
  • Architectures: amd64, arm64
  • Owners: eng, qe
  • Metrics and regression tracking: enabled
  • Base releases use ga-30d to ga for GA'd releases
  1. Suite Registration (pkg/db/suites.go)
  • Added Compliance-lp-interop to the test suites list
  1. Variant Registry (pkg/variantregistry/ocp.go)
  • Added mapping rules for compliance jobs tagged as LayeredProduct lp-interop-compliance:
    • Jobs containing -complianceascode- (upstream tests)
    • Jobs containing -compliance-destructive (downstream destructive tests)
    • Jobs containing -compliance (downstream tests)
  1. Snapshot (pkg/variantregistry/snapshot.yaml)
  • Updated 66 compliance job entries to use LayeredProduct: lp-interop-compliance

Related Jobs

This tracks the following Compliance periodic jobs:

Upstream (ComplianceAsCode) Jobs:

  • periodic-ci-ComplianceAsCode-content-master-{version}-e2e-aws-openshift-node-compliance (amd64/arm64)
  • periodic-ci-ComplianceAsCode-content-master-{version}-e2e-aws-openshift-platform-compliance (amd64/arm64)

Downstream Jobs:

  • periodic-ci-openshift-openshift-tests-private-release-{version}-{arch}-nightly-{platform}-*-compliance
  • periodic-ci-openshift-openshift-tests-private-release-{version}-{arch}-nightly-{platform}-*-compliance-destructive

Coverage includes versions 4.12-4.21 across amd64, arm64, and multi architectures on platforms: aws, azure, gcp, baremetal, vsphere.

  1. Testing
  • Views follow the established naming pattern: {OCP_RELEASE}-lp-Interop-{product}
  • Configuration aligns with other LP-Interop views (CNV, Quay, ServiceMesh, COO, etc.)
  • Metrics and regression tracking enabled for proactive monitoring
  • Both engineering and QE owned jobs are included for comprehensive coverage

Summary by CodeRabbit

  • New Features

  • Expanded multi-release readiness coverage with additional lp-interop-compliance historical releases and aligned release anchors.

  • Broader variant dimensions (architectures, platforms, layered-product variants, owners) for cross-release comparison.

  • Tests

  • Added a dedicated compliance test suite and consolidated periodic snapshots under the compliance grouping.

  • Chores

  • Standardized configuration and snapshot defaults for compliance-oriented variants.

✏️ Tip: You can customize this high-level summary in your review settings.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

@xiaojiey xiaojiey force-pushed the compliance-dashboard branch 2 times, most recently from 0387a9f to fd89f14 Compare January 16, 2026 04:32
@openshift-ci-robot
Copy link

openshift-ci-robot commented Jan 16, 2026

@xiaojiey: This pull request references CMP-3987 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.22.0" version, but no target version was set.

Details

In response to this:

Overview

  1. This PR adds support for tracking Component Readiness for the Compliance Operator as a separate layered product dashboard. The Compliance Operator includes both upstream (ComplianceAsCode) and downstream testing, and we need dedicated dashboards to track readiness across these components.

  2. Component Readiness views are added for Compliance across actively supported OCP versions (4.16-4.21).

Changes

  1. Configuration Views (config/views.yaml)

Added Component Readiness views for Compliance across OCP versions:

  • 4.22-lp-Interop-compliance: Compares 4.22 vs 4.21
  • 4.21-lp-Interop-compliance: Compares 4.21 vs 4.20
  • 4.20-lp-Interop-compliance: Compares 4.20 vs 4.19
  • 4.19-lp-Interop-compliance: Compares 4.19 vs 4.18
  • 4.18-lp-Interop-compliance: Compares 4.18 vs 4.17
  • 4.17-lp-Interop-compliance: Compares 4.17 vs 4.16
  • 4.16-lp-Interop-compliance: Compares 4.16 vs 4.15
  1. All views are configured with:
  • LayeredProduct filter: lp-interop-compliance
  • Platforms: azure, gcp, aws
  • Architectures: amd64, arm64
  • Owners: eng, qe
  • Metrics and regression tracking: enabled
  • Base releases use ga-30d to ga for GA'd releases
  1. Suite Registration (pkg/db/suites.go)
  • Added Compliance-lp-interop to the test suites list
  1. Variant Registry (pkg/variantregistry/ocp.go)
  • Added mapping rules for compliance jobs tagged as LayeredProduct lp-interop-compliance:
    • Jobs containing -complianceascode- (upstream tests)
    • Jobs containing -compliance-destructive (downstream destructive tests)
    • Jobs containing -compliance (downstream tests)
  1. Snapshot (pkg/variantregistry/snapshot.yaml)
  • Updated 66 compliance job entries to use LayeredProduct: lp-interop-compliance

Related Jobs

This tracks the following Compliance periodic jobs:

Upstream (ComplianceAsCode) Jobs:

  • periodic-ci-ComplianceAsCode-content-master-{version}-e2e-aws-openshift-node-compliance (amd64/arm64)
  • periodic-ci-ComplianceAsCode-content-master-{version}-e2e-aws-openshift-platform-compliance (amd64/arm64)

Downstream Jobs:

  • periodic-ci-openshift-openshift-tests-private-release-{version}-{arch}-nightly-{platform}-*-compliance
  • periodic-ci-openshift-openshift-tests-private-release-{version}-{arch}-nightly-{platform}-*-compliance-destructive

Coverage includes versions 4.12-4.21 across amd64, arm64, and multi architectures on platforms: aws, azure, gcp, baremetal, vsphere.

  1. Testing
  • Views follow the established naming pattern: {OCP_RELEASE}-lp-Interop-{product}
  • Configuration aligns with other LP-Interop views (CNV, Quay, ServiceMesh, COO, etc.)
  • Metrics and regression tracking enabled for proactive monitoring
  • Both engineering and QE owned jobs are included for comprehensive coverage

Summary by CodeRabbit

  • New Features

  • Expanded multi-release readiness coverage with additional lp-interop-compliance historical releases and aligned release anchors.

  • Broader variant dimensions for cross-release comparison (architectures, platforms, layered-product variants, owners).

  • Tests

  • Added a dedicated compliance test suite and consolidated periodic snapshots under the compliance grouping.

  • Chores

  • Standardized configuration and snapshot defaults for compliance-oriented variants.

✏️ Tip: You can customize this high-level summary in your review settings.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

@xiaojiey xiaojiey force-pushed the compliance-dashboard branch 2 times, most recently from 044adc8 to 63d8502 Compare January 16, 2026 05:45
Update regression_tracking and base_release per comments

Add 4.22 dashboard

Revert change for package-lock.json
@openshift-ci
Copy link
Contributor

openshift-ci bot commented Jan 16, 2026

@xiaojiey: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name Commit Details Required Rerun command
ci/prow/lint 63d8502 link true /test lint

Full PR test history. Your PR dashboard.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.

@openshift-ci-robot
Copy link

openshift-ci-robot commented Jan 16, 2026

@xiaojiey: This pull request references CMP-3987 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.22.0" version, but no target version was set.

Details

In response to this:

Overview

  1. This PR adds support for tracking Component Readiness for the Compliance Operator as a separate layered product dashboard. The Compliance Operator includes both upstream (ComplianceAsCode) and downstream testing, and we need dedicated dashboards to track readiness across these components.

  2. Component Readiness views are added for Compliance across actively supported OCP versions (4.16-4.21).

Changes

  1. Configuration Views (config/views.yaml)

Added Component Readiness views for Compliance across OCP versions:

  • 4.22-lp-Interop-compliance: Compares 4.22 vs 4.21
  • 4.21-lp-Interop-compliance: Compares 4.21 vs 4.20
  • 4.20-lp-Interop-compliance: Compares 4.20 vs 4.19
  • 4.19-lp-Interop-compliance: Compares 4.19 vs 4.18
  • 4.18-lp-Interop-compliance: Compares 4.18 vs 4.17
  • 4.17-lp-Interop-compliance: Compares 4.17 vs 4.16
  • 4.16-lp-Interop-compliance: Compares 4.16 vs 4.15
  1. All views are configured with:
  • LayeredProduct filter: lp-interop-compliance
  • Platforms: azure, gcp, aws
  • Architectures: amd64, arm64
  • Owners: eng, qe
  • Metrics and regression tracking: enabled
  • Base releases use ga-30d to ga for GA'd releases
  1. Suite Registration (pkg/db/suites.go)
  • Added Compliance-lp-interop to the test suites list
  1. Variant Registry (pkg/variantregistry/ocp.go)
  • Added mapping rules for compliance jobs tagged as LayeredProduct lp-interop-compliance:
    • Jobs containing -complianceascode- (upstream tests)
    • Jobs containing -compliance-destructive (downstream destructive tests)
    • Jobs containing -compliance (downstream tests)
  1. Snapshot (pkg/variantregistry/snapshot.yaml)
  • Updated 66 compliance job entries to use LayeredProduct: lp-interop-compliance

Related Jobs

This tracks the following Compliance periodic jobs:

Upstream (ComplianceAsCode) Jobs:

  • periodic-ci-ComplianceAsCode-content-master-{version}-e2e-aws-openshift-node-compliance (amd64/arm64)
  • periodic-ci-ComplianceAsCode-content-master-{version}-e2e-aws-openshift-platform-compliance (amd64/arm64)

Downstream Jobs:

  • periodic-ci-openshift-openshift-tests-private-release-{version}-{arch}-nightly-{platform}-*-compliance
  • periodic-ci-openshift-openshift-tests-private-release-{version}-{arch}-nightly-{platform}-*-compliance-destructive

Coverage includes versions 4.12-4.21 across amd64, arm64, and multi architectures on platforms: aws, azure, gcp, baremetal, vsphere.

  1. Testing
  • Views follow the established naming pattern: {OCP_RELEASE}-lp-Interop-{product}
  • Configuration aligns with other LP-Interop views (CNV, Quay, ServiceMesh, COO, etc.)
  • Metrics and regression tracking enabled for proactive monitoring
  • Both engineering and QE owned jobs are included for comprehensive coverage

Summary by CodeRabbit

  • New Features

  • Added multiple historical lp-interop-compliance releases for broader readiness and aligned release anchors.

  • Expanded variant dimensions to include additional architectures, platforms, layered-product options, and owners for cross-release comparison.

  • Tests

  • Introduced a dedicated compliance test suite and consolidated periodic snapshots under the compliance grouping.

  • Chores

  • Standardized configuration and snapshot defaults for compliance-oriented variants.

✏️ Tip: You can customize this high-level summary in your review settings.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

jira/valid-reference Indicates that this PR references a valid Jira ticket of any type.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants