TRT-2505: Add major update variant

[petr-muller]

The first commit is the most direct approach using a regexp suggested by TRT-2505; any upgrade job following a certain name pattern where the last version is suffixed with a -major segment is considered to be a major update job.

The second commit overwrites the direct approach with a slightly more ambitious change that centralizes upgrade variant detection code into a single method over the version.Version data structures, with a fallback to substring matches. I prefer this variant but kept it in a separate commit for the case we'd prefer the minimal change.

Summary by CodeRabbit

• New Features

  • Improved upgrade detection: classification now distinguishes major, minor, micro, and multi-step upgrades with better fallbacks and ordering validation.
  • More accurate determination of source/target releases to populate upgrade metadata.

• Tests

  • Expanded test coverage with many new scenarios (aggregates, nightly/upstream, cross-release, arch/platform variants).

• Chores

  • Adjusted snapshot data to refine upgrade level annotations.

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

[openshift-ci-robot]

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-robot]

@petr-muller: This pull request references TRT-2505 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:

This is the most direct approach suggested by TRT-2505; any upgrade job following a typical update job name pattern where the last version is suffixed with a -major segment is considered to be a major update job.

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]

Walkthrough

Switches release extraction to return parsed version.Version slices, broadens upgrade-detection regex and replaces prior string-based multi/minor logic with a new upgradeVariant(logger, releases, jobName) helper; updates setRelease to use Version. Adds many test cases and small snapshot value changes.

Changes

Cohort / File(s)	Summary
Variant registry logic pkg/variantregistry/ocp.go	Replaced string-based release parsing with extractReleases(jobName) []version.Version; renamed regex upgradeMinorRegex → upgradeMajorMinorRegex; added upgradeVariant(logger, releases, jobName) string; setRelease now accepts logger logrus.FieldLogger and populates Release/FromRelease fields using Original() and Segments(); sorting, deduplication and nil-handling adjusted. Review: parsing, sort/compare, nil returns, and logger warnings.
Tests (expanded cases) pkg/variantregistry/ocp_test.go	Added numerous table-driven test entries to TestVariantSyncer exercising aggregated upgrades, nightly/upstream scenarios, platform/arch variations, and many release-from/to combinations; verify variant maps (Release/FromRelease/upgrade classification). Review: expected variant values and new edge cases.
Snapshots pkg/variantregistry/snapshot.yaml	Updated several periodic snapshot entries changing Upgrade from minor to micro. Review: verify intended semantic change in snapshot data only.

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 28.57% 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 title 'TRT-2505: Add major update variant' directly and specifically describes the main change: introducing support for a 'major' update variant, which aligns with the core refactoring from multi-upgrade logic to a nuanced upgradeVariant pathway that classifies upgrades as major, minor, micro, or multi.
Go Error Handling	✅ Passed	Error handling follows Go best practices with proper error checks, nil validation before dereferences, bounds checking in slice access, error wrapping with context, and no inappropriate panic() calls.
Sql Injection Prevention	✅ Passed	Pull request modifies variant detection logic in ocp.go without introducing SQL injection vulnerabilities since job names are only processed locally after safe retrieval from the database.
Excessive Css In React Should Use Styles	✅ Passed	This check is not applicable to the provided pull request. The PR modifies Go source code files and a YAML configuration file, which are backend infrastructure components. The custom check is specifically designed for React components with inline CSS/styled objects, and does not apply to Go backend code.
Single Responsibility And Clear Naming	✅ Passed	The pull request maintains strong adherence to single responsibility and clear naming principles with focused fields and consistently action-oriented method names.

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

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

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

[petr-muller]

/hold

I'd like to clarify some details in TRT-2505 first

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: petr-muller
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:

• OWNERS

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

[openshift-ci-robot]

@petr-muller: This pull request references TRT-2505 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:

This is the most direct approach suggested by TRT-2505; any upgrade job following a typical update job name pattern where the last version is suffixed with a -major segment is considered to be a major update job.

Summary by CodeRabbit

• New Features

• Enhanced upgrade detection now recognizes major version upgrades.

• Tests

• Added test coverage for major upgrade detection scenarios.

_{✏️ 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]

Scheduling required tests:
/test e2e

[openshift-ci-robot]

@petr-muller: This pull request references TRT-2505 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:

This is the most direct approach suggested by TRT-2505; any upgrade job following a typical update job name pattern where the last version is suffixed with a -major segment is considered to be a major update job.

Summary by CodeRabbit

• New Features

• Improved upgrade detection and classification now recognizes major, minor, micro, and multi-step upgrades with better fallbacks for ambiguous versions.

• More accurate extraction of source/target release bounds to populate upgrade metadata.

• Tests

• Added coverage for major-upgrade-from-nightly scenarios to ensure correct variant detection.

_{✏️ 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.

[coderabbitai]

Actionable comments posted: 1

🤖 Fix all issues with AI agents

In `@pkg/variantregistry/ocp.go`:
- Around line 320-323: The major/minor upgrade detection regexes
(upgradeMajorMinorRegex and related upgradeOutOfChangeRegex/upgradeRegex) are
too strict and miss common adjacent-version forms like "-4.10-4.11" or
"-4.10-to-4.11", causing upgradeVariant logic to misclassify as "micro"; update
upgradeMajorMinorRegex to also match two adjacent version tokens separated by a
single token (dash, "to", or similar single-token separators) and ensure it
still detects single-version-major markers like "-4.10-major" and "-4.10-minor";
verify the adjusted pattern is used by the upgradeVariant code path and keep
upgradeOutOfChangeRegex and upgradeRegex semantics unchanged while broadening
allowed separators so typical "-4.10-4.11" and "-4.10-to-4.11" job names are
classified as major/minor upgrades.

[openshift-ci-robot]

@petr-muller: This pull request references TRT-2505 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:

This is the most direct approach suggested by TRT-2505; any upgrade job following a typical update job name pattern where the last version is suffixed with a -major segment is considered to be a major update job.

Summary by CodeRabbit

• New Features

• Improved upgrade detection and classification now recognizes major, minor, micro, and multi-step upgrades with better fallbacks for ambiguous versions.

• More robust release parsing that produces structured source/target release info for variant metadata.

• Tests

• Added test cases covering major/minor upgrade scenarios (including nightly and stable origins) across platforms.

• Bug Fixes

• Updated snapshot entries to correct upgrade level semantics (minor → micro) for periodic jobs.

_{✏️ 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]

@petr-muller: This pull request references TRT-2505 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:

The first commit is the most direct approach using a regexp suggested by TRT-2505; any upgrade job following a certain name pattern where the last version is suffixed with a -major segment is considered to be a major update job.

The second commit overwrites the direct approach with a slightly more ambitious change that centralizes upgrade variant detection code into a single method over the version.Version data structures, with a fallback to substring matches. I prefer this variant but kept it in a separate commit for the case we'd prefer the minimal change.

Summary by CodeRabbit

• New Features

• Improved upgrade detection and classification now recognizes major, minor, micro, and multi-step upgrades with better fallbacks for ambiguous versions.

• More accurate extraction of source/target release bounds to populate upgrade metadata.

• Tests

• Added coverage for major-upgrade-from-nightly scenarios to ensure correct variant detection.

_{✏️ 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.

[petr-muller]

/hold cancel

[petr-muller]

The job name is ...release-4.12-amd64-nightly-4.12-upgrade-from-aro-4.12-aro-f60 so previously these were misclassified.

[openshift-ci-robot]

Scheduling required tests:
/test e2e

[openshift-ci-robot]

@petr-muller: This pull request references TRT-2505 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:

The first commit is the most direct approach using a regexp suggested by TRT-2505; any upgrade job following a certain name pattern where the last version is suffixed with a -major segment is considered to be a major update job.

The second commit overwrites the direct approach with a slightly more ambitious change that centralizes upgrade variant detection code into a single method over the version.Version data structures, with a fallback to substring matches. I prefer this variant but kept it in a separate commit for the case we'd prefer the minimal change.

Summary by CodeRabbit

• New Features

• Improved upgrade detection: classification now distinguishes major, minor, micro, and multi-step upgrades with better fallbacks and ordering validation.

• More accurate determination of source/target releases to populate upgrade metadata.

• Tests

• Expanded test coverage with many new scenarios (aggregates, nightly/upstream, cross-release, arch/platform variants).

• Chores

• Adjusted snapshot data to refine upgrade level annotations.

_{✏️ 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]

Scheduling required tests:
/test e2e

[openshift-ci]

@petr-muller: 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.