CORENET-6861: Make BGP jobs candidate

[tssurya]

Figured the bgp/evpn tests were showing up as hidden when we tried to link sippy jobs to feature gates: openshift/api#2799 (comment)

Summary by CodeRabbit

• Bug Fixes
  • BGP-related jobs previously classified as hidden are now classified as candidate, restoring expected visibility.
  • Job tier updated across multiple release variants to ensure consistent classification for both default and techpreview feature sets.
  • Improves discoverability and consistency of periodic CI job listings.

[openshift-merge-bot]

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

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Repository YAML (base), Central YAML (inherited)

Review profile: CHILL

Plan: Enterprise

Run ID: 2b78e9be-9eaf-4111-b173-19ba4771b9d4

📥 Commits

Reviewing files that changed from the base of the PR and between a3bb544 and 6ae622e.

📒 Files selected for processing (2)

• pkg/variantregistry/ocp.go
• pkg/variantregistry/snapshot.yaml

✅ Files skipped from review due to trivial changes (1)

• pkg/variantregistry/snapshot.yaml

🚧 Files skipped from review as they are similar to previous changes (1)

• pkg/variantregistry/ocp.go

---

Walkthrough

BGP-related CI jobs are reclassified from hidden to candidate. The code change adjusts the job-tier matching order/pattern so -bgp- names match an earlier candidate pattern, and the snapshot YAML entries update JobTier for periodic OVN BGP jobs across releases 4.19–5.0.

Changes

Cohort / File(s)	Summary
Job Tier Classification Logic pkg/variantregistry/ocp.go	Adjusted job-tier matching so jobs containing -bgp- now match an earlier pattern and are assigned the candidate tier instead of being matched by the later hidden rule.
Snapshot Data pkg/variantregistry/snapshot.yaml	Updated multiple periodic-ci-openshift-ovn-kubernetes-release-* entries (releases 4.19–5.0, both FeatureSet: default and FeatureSet: techpreview where present) to change JobTier from hidden to candidate.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

🚥 Pre-merge checks | ✅ 15 | ❌ 2

❌ Failed checks (1 warning, 1 inconclusive)

Check name	Status	Explanation	Resolution
Title check	⚠️ Warning	The PR title references making BGP jobs 'standard', but the actual change demotes them from 'hidden' to 'candidate' tier, not to 'standard' as the title implies.	Update the title to accurately reflect the change (e.g., 'CORENET-6861: Promote BGP jobs to candidate tier' or 'CORENET-6861: Move BGP jobs from hidden to candidate').
Topology-Aware Scheduling Compatibility	❓ Inconclusive	Pull request analysis requires examination of actual code changes and deployment architecture context to assess scheduling constraint implications for HA topology.	Please provide the pull request diff, modified files content, and information about the target deployment architecture (standard HA topology specifications).

✅ Passed checks (15 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Go Error Handling	✅ Passed	The modified code in the setJobTier function contains no error handling operations, consisting entirely of job tier pattern entries with only string literals and struct assignments.
Sql Injection Prevention	✅ Passed	The PR modifies job tier classification logic and YAML configuration with no SQL operations, database connectivity, or dynamic query construction present in the codebase.
Excessive Css In React Should Use Styles	✅ Passed	This custom check is not applicable to the provided pull request. The PR modifies only Go source code and YAML configuration files with no React/JSX/TSX code.
Test Coverage For New Features	✅ Passed	Changes modify job tier classification patterns and configuration data which are covered under exceptions for configuration-only changes without requiring new test coverage.
Single Responsibility And Clear Naming	✅ Passed	The PR adheres to single responsibility and clear naming principles. The setJobTier method maintains a single, well-defined responsibility of classifying jobs by tier with minimal, localized changes.
Stable And Deterministic Test Names	✅ Passed	The PR modifies only job tier classification logic and YAML data; no Ginkgo test definitions or test code are modified.
Test Structure And Quality	✅ Passed	The pull request contains no Ginkgo test code, making the test code quality check not applicable to the scope of this PR.
Microshift Test Compatibility	✅ Passed	This PR modifies configuration and data files in the sippy repository, not test code. No Ginkgo e2e tests are being added.
Single Node Openshift (Sno) Test Compatibility	✅ Passed	This PR modifies configuration files in openshift/sippy, a CI analysis tool, not a Ginkgo e2e test repository. No new e2e tests are added.
Ote Binary Stdout Contract	✅ Passed	Pull request modifies only configuration and data files in variantregistry package without introducing stdout-writing code.
Ipv6 And Disconnected Network Test Compatibility	✅ Passed	This PR contains no new Ginkgo e2e tests, only configuration and metadata updates to the sippy CI job analysis tool.

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

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

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.11.4)

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.}

[tssurya]

@dgoodwin PTAL

[openshift-ci-robot]

@tssurya: This pull request references CORENET-6861 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 "5.0.0" version, but no target version was set.

Details

In response to this:

Figured the bgp/evpn tests were showing up as hidden when we tried to link sippy jobs to feature gates: openshift/api#2799 (comment)

Summary by CodeRabbit

• Bug Fixes
• BGP-related jobs are now properly classified as standard instead of hidden, improving their visibility and discoverability in the system.
• Updated job tier classifications across multiple release variants to ensure consistent behavior.

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.

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@pkg/variantregistry/ocp.go`:
- Around line 758-759: The entry {[]string{"-bgp-"}, "standard"} in
pkg/variantregistry/ocp.go is too broad and currently placed before more
specific safety rules (e.g., the later "-recovery", "-disruptive", and
"-rollback" checks), so it prematurely returns "standard"; fix by either
narrowing the pattern (make it specific to OVN-Kubernetes BGP job names) or
moving the {[]string{"-bgp-"}, "standard"} entry below the more specific checks
(the "-recovery" check and the "-disruptive"/"-rollback" checks) so those
specific matches take precedence when evaluating the rules.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Repository YAML (base), Central YAML (inherited)

Review profile: CHILL

Plan: Enterprise

Run ID: 695f2fee-9cfe-4c99-8eed-9c16b6bdee67

📥 Commits

Reviewing files that changed from the base of the PR and between ef5d2d8 and a3bb544.

📒 Files selected for processing (2)

• pkg/variantregistry/ocp.go
• pkg/variantregistry/snapshot.yaml

[openshift-ci]

@coderabbitai[bot]: changing LGTM is restricted to collaborators

Details

In response to this:

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@pkg/variantregistry/ocp.go`:
- Around line 758-759: The entry {[]string{"-bgp-"}, "standard"} in
pkg/variantregistry/ocp.go is too broad and currently placed before more
specific safety rules (e.g., the later "-recovery", "-disruptive", and
"-rollback" checks), so it prematurely returns "standard"; fix by either
narrowing the pattern (make it specific to OVN-Kubernetes BGP job names) or
moving the {[]string{"-bgp-"}, "standard"} entry below the more specific checks
(the "-recovery" check and the "-disruptive"/"-rollback" checks) so those
specific matches take precedence when evaluating the rules.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Repository YAML (base), Central YAML (inherited)

Review profile: CHILL

Plan: Enterprise

Run ID: 695f2fee-9cfe-4c99-8eed-9c16b6bdee67

📥 Commits

Reviewing files that changed from the base of the PR and between ef5d2d8 and a3bb544.

📒 Files selected for processing (2)

• pkg/variantregistry/ocp.go
• pkg/variantregistry/snapshot.yaml

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.

[openshift-merge-bot]

Scheduling required tests:
/test e2e

[dgoodwin]

This will bring these jobs into the main component readiness view for 4.22. A quick test indicates that means 48 new regressions at a critical time. We can't promote to standard until these jobs are stabilized.

You can move them to 'candidate' and that will appear in the api promotion results to get you through, but the feature will have no coverage for monitored testing at the org level going forward until they are stable and in standard.

[tssurya]

This will bring these jobs into the main component readiness view for 4.22. A quick test indicates that means 48 new regressions at a critical time. We can't promote to standard until these jobs are stabilized.

why 4.22? Is there a way to do it for 5.0 which is still early in its cycle.?

You can move them to 'candidate' and that will appear in the api promotion results to get you through, but the feature will have no coverage for monitored testing at the org level going forward until they are stable and in standard.

what's the criteria for them to get stabilized?
the way I see it.. I need 14 runs over 14 days to show stability which makes sense so I guess we can keep these as "candidate" until that happens and then get it to standard? Is that fair?

Also note that "bgp" job has been around since last year and we were running "bgp" tests all this while, what we do now is add "Evpn" new tests to the mix - so its new tests we are adding to existing jobs, not new jobs

[dgoodwin]

Yes I understand the jobs are old but they were hidden from signal due to instability at some point.

The variants file does know about releases, so you can conditionally go to standard if 5.0+ and deal with the regressions that come in this release cycle.

[tssurya]

@dgoodwin ack, I've updated this PR to make them candidate for now.. I have some questions around this and a few other things which I can bring it up in the new QSE Call

[openshift-ci]

@coderabbitai[bot]: changing LGTM is restricted to collaborators

Details

In response to this:

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.

[openshift-merge-bot]

Scheduling required tests:
/test e2e

[openshift-ci]

@tssurya: all tests passed!

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.

[dgoodwin]

/lgtm

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: coderabbitai[bot], dgoodwin, tssurya

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

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [dgoodwin]

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

[tssurya]

@dgoodwin It seems making it candidate still doesn't fix JobTier: hidden issue here: https://sippy-auth.dptools.openshift.org/sippy-ng/tests/5.0/details?filters=%7B%22items%22%3A%5B%7B%22columnField%22%3A%22name%22%2C%22operatorValue%22%3A%22contains%22%2C%22value%22%3A%22FeatureGate%3AEVPN%5D%22%7D%5D%7D and its not showing up in the feature gate promotion PR - do I need to wait for sometime till my fix lands into the prod sippy?

error: only 0 tests found, need at least 5 for "EVPN" on {metal amd64 ha dual   false}

[dgoodwin]

It runs early morning EST, it's possible it's corrected since I posted, I see data in your link, if something is missing there let me know and we'll dig deeper. Job variants visible here: https://sippy-auth.dptools.openshift.org/sippy-ng/jobs/5.0?filters=%257B%2522items%2522%253A%255B%257B%2522columnField%2522%253A%2522variants%2522%252C%2522operatorValue%2522%253A%2522has%2520entry%2522%252C%2522value%2522%253A%2522never-stable%2522%252C%2522not%2522%253Atrue%257D%252C%257B%2522id%2522%253A99%252C%2522columnField%2522%253A%2522name%2522%252C%2522operatorValue%2522%253A%2522contains%2522%252C%2522value%2522%253A%2522-bgp-%2522%257D%255D%257D&sort=asc&sortField=name&view=Variants

[tssurya]

@dgoodwin all good! It was a timing issue yea

error: "[Feature:EVPN][Feature:RouteAdvertisements][FeatureGate:EVPN][ovn-kubernetes-ote][sig-network] BGP: For BGP configured networks When the tested network is of type Layer 2 CUDN EVPN MAC-VRF and IP-VRF When a pod runs on the tested network Can reach KAPI service [Suite:openshift/conformance/parallel]" only has 5 runs, need at least 14 runs for "EVPN" on {metal amd64 ha dual   false}
error: "[Feature:EVPN][Feature:RouteAdvertisements][FeatureGate:EVPN][ovn-kubernetes-ote][sig-network] BGP: For BGP configured networks When the tested network is of type Layer 2 CUDN EVPN MAC-VRF and IP-VRF When a pod runs on the tested network Can reach KAPI service [Suite:openshift/conformance/parallel]" only passed 80%, need at least 95% for "EVPN" on {metal amd64 ha dual   false}
error: "[Feature:EVPN][Feature:RouteAdvertisements][FeatureGate:EVPN][ovn-kubernetes-ote][sig-network] BGP: For BGP configured networks When the tested network is of type Layer 2 CUDN EVPN MAC-VRF and IP-VRF When a pod runs on the tested network It can be reached by an external server on the same network When the network is IPv4 [Suite:openshift/conformance/parallel]" only has 5 runs, need at least 14 runs for "EVPN" on {metal amd64 ha dual   false}
error: "[Feature:EVPN][Feature:RouteAdvertisements][FeatureGate:EVPN][ovn-kubernetes-ote][sig-network] BGP: For BGP configured networks When the tested network is of type Layer 2 CUDN EVPN MAC-VRF and IP-VRF When a pod runs on the tested network It can be reached by an external server on the same network When the network is IPv6 [Suite:openshift/conformance/parallel]" only has 5 runs, need at least 14 runs for "EVPN" on {metal amd64 ha dual   false}

seems to work now