Check Z-stream clone status before deciding Y-stream Low/Moderate eli…

[lbarcziova]

…gibility

For Low/Moderate Y-stream CVEs, the previous logic returned NEVER ("CentOS Stream first") without verifying whether the Z-stream clone had actually shipped. This created a race condition: if Z-stream branched after the check but before the fix landed, the Y-stream CVE would be permanently skipped even though CentOS Stream inheritance no longer applied.

The new flow always checks Z-stream clone dependencies first:

• Clones not shipped → PENDING_DEPENDENCIES (wait for confirmation)
• Clones shipped + Z-stream not branched → NEVER (fix confirmed in CentOS Stream, Y-stream inherits)
• Clones shipped + Z-stream branched → IMMEDIATELY (fix went through internal branch, Y-stream needs its own triage)

The dependency check for Low/Moderate is scoped to the same RHEL major version, since CentOS Stream inheritance only works within a major version (e.g. CentOS Stream 9 feeds RHEL 9.x, not RHEL 10.x).

Also adds ogr to the c9s test container for the GitLab branch check import and updates eligibility reason strings to use "CentOS Stream first approach" / "RHEL first approach" terminology.

Assisted-by: Claude Opus 4.6

[gemini-code-assist]

Code Review

This pull request updates the triage eligibility logic for low and moderate severity Y-stream CVEs by checking if the corresponding Z-stream has already branched internally. It also adds the ogr dependency to the test container and introduces comprehensive unit tests for the new branching logic. The review feedback highlights two critical issues: first, the blocker reason should only be overwritten when the eligibility is PENDING_DEPENDENCIES to avoid misleading status messages; second, transient failures when checking the Z-stream branch should raise a ToolError rather than silently returning False, which could permanently skip triage.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

If _check_for_dependency_blocker returns a blocker with TriageEligibility.NEVER (for example, because the CVE ID cannot be extracted or no component is set on the issue), overwriting the reason to say "waiting for Z-stream clone to ship" is incorrect and highly misleading. It contradicts the NEVER eligibility status and hides the actual error.

We should only overwrite the reason if the blocker's eligibility is indeed PENDING_DEPENDENCIES.

Suggested change

	if is_low_moderate:
	blocker.result["reason"] = (
	f"Y-stream CVE ({target_version}, {severity} severity): "
	f"waiting for RHEL-{major_version} Z-stream clone to ship "
	"to determine fix path (CentOS Stream first or RHEL first approach)"
	)
	if is_low_moderate and blocker.result.get("eligibility") == TriageEligibility.PENDING_DEPENDENCIES:
	blocker.result["reason"] = (
	f"Y-stream CVE ({target_version}, {severity} severity): "
	f"waiting for RHEL-{major_version} Z-stream clone to ship "
	"to determine fix path (CentOS Stream first or RHEL first approach)"
	)

[gemini-code-assist]

If checking the Z-stream branch fails due to a transient GitLab API error or network issue, returning False will cause the eligibility to be determined as NEVER (CentOS Stream first approach, fix will be inherited). This results in the Y-stream CVE being permanently skipped and never triaged.

Instead of silently skipping the CVE on transient failures, we should raise a ToolError so that the framework/orchestrator knows the tool execution failed and can retry it later.

Suggested change

	except Exception as e:
	logger.warning(f"Failed to check if Z-stream branch {expected_branch} exists for {package}: {e}")
	return False
	except Exception as e:
	raise ToolError(
	f"Failed to check if Z-stream branch {expected_branch} exists for {package}: {e}"
	) from e