Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion config/openshift-eng.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -24,7 +24,7 @@ includeSuites:
- Gitops-lp-interop
- ACS-lp-interop
- OADP-lp-interop
- COO-lp-interop
- tracing-uiplugin
excludeSuites: []
excludeTests:
- "Build image%"
Expand Down
Original file line number Diff line number Diff line change
@@ -0,0 +1,4 @@
reviewers:
- IshwarKanse
approvers:
- IshwarKanse
Original file line number Diff line number Diff line change
@@ -0,0 +1,15 @@
package tracinguiplugin

import (
v1 "github.com/openshift-eng/ci-test-mapping/pkg/api/types/v1"
"github.com/openshift-eng/ci-test-mapping/pkg/util"
)

func identifyCapabilities(test *v1.TestInfo) []string {
capabilities := util.DefaultCapabilities(test)

// Extract [Capability:XXX] tags from test name
capabilities = append(capabilities, util.ExtractTestField(test.Name, "Capability")...)

return capabilities
}
Original file line number Diff line number Diff line change
@@ -0,0 +1,63 @@
package tracinguiplugin

import (
v1 "github.com/openshift-eng/ci-test-mapping/pkg/api/types/v1"
"github.com/openshift-eng/ci-test-mapping/pkg/config"
)

type Component struct {
*config.Component
}

var ClusterObservabilityOperatorComponent = Component{
Component: &config.Component{
Name: "tracing-uiplugin",
Operators: []string{"cluster-observability-operator"},
DefaultJiraProject: "COO",
Copy link
Contributor

Choose a reason for hiding this comment

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

We probably need to review what you need here. I don't think there is full support for Jira projects other than OCPBUGS currently for CR

Copy link
Member Author

Choose a reason for hiding this comment

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

Thanks for the feedback @neisw! I did some investigation using Claude Code of both the ci-test-mapping and Sippy codebases to understand the limitations.

What I Found

I found only one limitation for non-OCPBUGS Jira projects:

Triage Auto-Commenting (sippy/pkg/api/componentreadiness/triage.go:140-141)

if !strings.HasPrefix(jiraCard, "OCPBUGS") {
    logger.Warnf("URL (%s) is not an OCPBUGS card, cannot comment", triage.URL)
    return
}
  • When users triage test failures and link them to Jira issues, Sippy won't automatically add comments to COO Jira cards
  • This is a convenience feature.

What Works

I verified that all core Component Readiness features properly support non-OCPBUGS projects:

Test Data Storage - sippy/pkg/apis/sippy/v1/types.go:95-96

// JiraProject specifies the JIRA project that this variant belongs to.
JiraProject string `bigquery:"jira_project"`

Variant Mappings - sippy/pkg/componentreadiness/jiraautomator/jiraautomator.go:636

result[Variant{...}] = JiraComponent{Project: r.JiraProject, Component: r.JiraComponent}

Jira Automation - Not applicable to COO

  • COO dashboards have regression_tracking: enabled: false in config/views.yaml
  • While jiraautomator.go:546 defaults to OCPBUGS for row-based components, this code path isn't used for COO since automation is disabled

Dashboard Configuration - sippy/config/views.yaml

  • COO dashboards filter by LayeredProduct: lp-interop-coo, not by Jira project
  • No Jira project restrictions in dashboard definitions

Queries and Filtering - sippy/pkg/api/componentreadiness/query/querygenerators.go

  • No hardcoded OCPBUGS requirements in query generation
  • Only reference to OCPBUGS is a comment about a bug (line 40)

Frontend Bug Filing - sippy-ng/src/bugs/FileBug.js

  • Takes jiraComponentID and jiraComponentName as generic props
  • No hardcoded project restrictions

The system is properly architected to support multiple Jira projects - the data model, queries, and dashboards all handle it correctly.

My Plan

We can keep the COO project since:

  1. It aligns with our team's Jira workflow
  2. All core functionality works (statistics, dashboards, data storage)
  3. We only lose one convenience feature (triage auto-commenting)
  4. Jira automation doesn't apply to COO (regression tracking is disabled)
  5. The enhancement to support other projects should be straightforward (removing one hardcoded check). I can work on it in another PR.

Does this work, or are there other concerns we should address?

Copy link
Contributor

Choose a reason for hiding this comment

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

Thanks @IshwarKanse, I double checked with the team and our code and unfortunately there is still a dependency that components be defined in OCPBUGS project. We do understand that this is a limitation for teams who do not typically work within the OCPBUGS project and are trying to utilize CR. For the near term you will need to define a component within OCPBUGS and associate your suite with it for CR to display the results properly.

Copy link
Member Author

@IshwarKanse IshwarKanse Jan 8, 2026

Choose a reason for hiding this comment

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

Thanks @neisw for the clarification! I've reviewed the code and understand the limitation.

You're right - both ci-test-mapping (pkg/jira/ocpbugs.go:19) and Sippy (pkg/dataloader/jiraloader/jiraloader.go:122) hardcode the OCPBUGS project ID when loading component IDs.

I also found that bug filing is hardcoded to OCPBUGS (pkg/sippyserver/server.go:1675), so filing bugs from Sippy UI won't work for COO components.

What Works vs What Doesn't

Feature With COO Project
Dashboard display ✓ Works
Statistics & regressions ✓ Works
Bug filing from Sippy UI ✗ Won't work (must file directly in COO Jira)
Triage auto-commenting ✗ Won't work

The core dashboard functionality works because jira_component_id isn't used for filtering (there's even a TODO at querygenerators.go:311 noting it appears unused).

Our Situation

We can't create a component in OCPBUGS since COO is a layered product with its own Jira project and it has many components. I noticed other layered products (CNV, ODF, Quay) work around this by creating components in OCPBUGS, but we'd prefer to keep proper Jira alignment as all the bugs being reported against COO components will mix with the bugs in OCPBUGS jira project.

We're OK accepting these limitations (no Sippy bug filing, no triage commenting) in exchange for proper COO Jira project alignment. Our teams will file bugs directly in COO Jira.

That said, if you'd prefer we follow the existing pattern for consistency, we can remove DefaultJiraProject: "COO" and create the components in OCPBUGS instead. Let me know your preference and I'll update the PR accordingly. Thank you for your time looking into this.

Copy link
Contributor

Choose a reason for hiding this comment

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

Unfortunately neither the dashboard or statistics work with this configuration currently. We know Sippy/CR are very OCP centric and have longer term goals to abstract many of the assumptions that have been built in. But currently you can see that when we fail to identify a test / component mapping we return an error and do not update the mappings until the issue is corrected.

Sippy queries the tests and joins with the component mappings via querygenerators

If we don't have a test mapped to an OCPBUGs component then that test will not be returned in the results currently. If you run through the ci-test-mappings jira-verify command you can see the failure:
ERRO[0000] unknown component "tracing-uiplugin" not found in jira

So unfortunately, in the near term, if you are looking to use CR you need a component defined in OCPBUGS that you can map your tests too. You don't have to use OCPBUGS, you views will not be blocking OCP or require regression manangment, etc. But just to get the view working you will need components that can be pulled from OCPBUGS for the time being.

I do appreciate your investigation, flexibility and communication on how you would prefer to use the tooling. For now though OCP remains our primary focus and until we can prioritize redesign we have to request flexibility from team outside of OCP that want to make use of the tooling.

Copy link
Member Author

Choose a reason for hiding this comment

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

@neisw Thank you for your response, I went ahead and raised a request to add our components to the OCPBUGS project. https://issues.redhat.com/browse/DPP-18951 Once that is completed, I'll update this PR to remove the defaultproject COO and then this will match what our rest of the layered product teams have implemented.

DefaultJiraComponent: "tracing-uiplugin",
Matchers: []config.ComponentMatcher{
{
Suite: "tracing-uiplugin",
},
},
},
}

func (c *Component) IdentifyTest(test *v1.TestInfo) (*v1.TestOwnership, error) {
if matcher := c.FindMatch(test); matcher != nil {
jira := matcher.JiraComponent
if jira == "" {
jira = c.DefaultJiraComponent
}
return &v1.TestOwnership{
Name: test.Name,
Component: c.Name,
JIRAComponent: jira,
Priority: matcher.Priority,
Capabilities: append(matcher.Capabilities, identifyCapabilities(test)...),
}, nil
}

return nil, nil
}

func (c *Component) StableID(test *v1.TestInfo) string {
// Look up the stable name for our test in our renamed tests map.
if stableName, ok := c.TestRenames[test.Name]; ok {
return stableName
}
return test.Name
}

func (c *Component) JiraComponents() (components []string) {
components = []string{c.DefaultJiraComponent}
for _, m := range c.Matchers {
components = append(components, m.JiraComponent)
}

return components
}

func (c *Component) ListNamespaces() []string {
return c.Namespaces
}
2 changes: 2 additions & 0 deletions pkg/registry/registry.go
Original file line number Diff line number Diff line change
Expand Up @@ -37,6 +37,7 @@ import (
cloudnativeeventshardwareeventproxy "github.com/openshift-eng/ci-test-mapping/pkg/components/cloudnativeevents/hardwareeventproxy"
"github.com/openshift-eng/ci-test-mapping/pkg/components/clusterautoscaler"
"github.com/openshift-eng/ci-test-mapping/pkg/components/clusterloader"
tracinguiplugin "github.com/openshift-eng/ci-test-mapping/pkg/components/clusterobservabilityoperator/tracinguiplugin"
"github.com/openshift-eng/ci-test-mapping/pkg/components/clusterresourceoverrideadmissionoperator"
"github.com/openshift-eng/ci-test-mapping/pkg/components/clusterversionoperator"
"github.com/openshift-eng/ci-test-mapping/pkg/components/cnfcerttnf"
Expand Down Expand Up @@ -267,6 +268,7 @@ func NewComponentRegistry() *Registry {
r.Register("Cloud Native Events / Hardware Event Proxy", &cloudnativeeventshardwareeventproxy.HardwareEventProxyComponent)
r.Register("Cluster Autoscaler", &clusterautoscaler.ClusterAutoscalerComponent)
r.Register("Cluster Loader", &clusterloader.ClusterLoaderComponent)
r.Register("tracing-uiplugin", &tracinguiplugin.ClusterObservabilityOperatorComponent)
r.Register("Cluster Resource Override Admission Operator", &clusterresourceoverrideadmissionoperator.ClusterResourceOverrideAdmissionOperatorComponent)
r.Register("Cluster Version Operator", &clusterversionoperator.ClusterVersionOperatorComponent)
r.Register("Console Metal3 Plugin", &consolemetal3plugin.ConsoleMetal3PluginComponent)
Expand Down