Skip to content

Verify dependency build is in buildroot before proceeding with rebuild#562

Merged
lbarcziova merged 1 commit into
packit:mainfrom
lbarcziova:rebuild-buildroot-check
Jun 3, 2026
Merged

Verify dependency build is in buildroot before proceeding with rebuild#562
lbarcziova merged 1 commit into
packit:mainfrom
lbarcziova:rebuild-buildroot-check

Conversation

@lbarcziova
Copy link
Copy Markdown
Member

Before triggering a rebuild, check that the dependency's fixed build has actually landed in the target buildroot (Koji build tag). Without this, a rebuild could link against the old dependency and silently not fix the CVE. If the build is not yet in the buildroot, postpone the rebuild.

The check queries the appropriate Koji instance(s) based on target branch and fix version:

  • CentOS Stream (c9s, c10s) Y-stream → c{N}s-build on CentOS Stream Koji
  • CentOS Stream Z-stream → c{N}s-build AND rhel-X.Y.0-z-build on BrewHub (CentOS Stream-first approach produces two builds)
  • Internal RHEL branches → rhel-X.Y.0-z-build on BrewHub

The epoch for EVR comparison is fetched via getBuild (always from BrewHub, since the NVR in Jira is a BrewHub NVR that doesn't exist in CentOS Stream Koji), not parsed from the NVR string.

The verification runs for both the primary rebuild issue (new verify_rebuild_buildroot workflow step) and for sibling issues during rebuild consolidation.

Also fixes the source-prep-failure path in check_cve_applicability to route rebuilds through the buildroot check instead of skipping directly to comment_in_jira.

Fixes: https://redhat.atlassian.net/browse/PACKIT-5072
Assisted-by: Claude Opus 4.6

Copy link
Copy Markdown
Contributor

@gemini-code-assist gemini-code-assist Bot left a comment

Choose a reason for hiding this comment

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

Code Review

This pull request introduces a buildroot verification step for rebuild tasks to ensure that a dependency's fixed build is available in the target buildroot before proceeding. It adds the verify_rebuild_buildroot step to the triage workflow, queries Koji/BrewHub buildroots, and postpones triage if dependencies are missing. A review comment suggests using indexing instead of list unpacking when retrieving the latest build to prevent potential ValueError exceptions.

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.

Comment thread ymir/common/utils.py Outdated
logger.info(f"No builds of {dep_component} found in {build_tag}")
return False

[latest] = builds
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

medium

Using list unpacking [latest] = builds is fragile because it will raise a ValueError if builds contains more than one element. It is safer and more robust to use indexing to retrieve the first element.

Suggested change
[latest] = builds
latest = builds[0]

nforro
nforro previously approved these changes Jun 3, 2026
Comment thread ymir/common/utils.py Outdated
Comment thread ymir/common/utils.py Outdated
Comment thread ymir/common/utils.py Outdated
@lbarcziova
Copy link
Copy Markdown
Member Author

@nforro implemented the suggestions, PTAL

nforro
nforro previously approved these changes Jun 3, 2026
Comment thread ymir/common/utils.py Outdated
Comment thread ymir/common/utils.py Outdated
Comment thread ymir/common/utils.py Outdated
Before triggering a rebuild, check that the dependency's fixed build has
actually landed in the target buildroot (Koji build tag). Without this,
a rebuild could link against the old dependency and silently not fix the
CVE. If the build is not yet in the buildroot, postpone the rebuild.

The check queries the appropriate Koji instance(s) based on target branch
and fix version:
- CentOS Stream (c9s, c10s) Y-stream → c{N}s-build on CentOS Stream Koji
- CentOS Stream Z-stream → c{N}s-build AND rhel-X.Y.0-z-build on BrewHub
  (CentOS Stream-first approach produces two builds)
- Internal RHEL branches → rhel-X.Y.0-z-build on BrewHub

The epoch for EVR comparison is fetched via getBuild (always from
BrewHub, since the NVR in Jira is a BrewHub NVR that doesn't exist
in CentOS Stream Koji), not parsed from the NVR string.

The verification runs for both the primary rebuild issue (new
verify_rebuild_buildroot workflow step) and for sibling issues during
rebuild consolidation.

Also fixes the source-prep-failure path in check_cve_applicability to
route rebuilds through the buildroot check instead of skipping directly
to comment_in_jira.

Fixes: https://redhat.atlassian.net/browse/PACKIT-5072
Assisted-by: Claude Opus 4.6
Comment thread ymir/common/utils.py
@@ -189,3 +202,76 @@ def get_latest_build(tag):
metadata = await asyncio.to_thread(session.getBuild, build_id, strict=True)
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

It would be great to use _get_koji_build() here, but that would require more changes as the lookup here is by build ID, not NVR.

@lbarcziova lbarcziova merged commit c1c9aa1 into packit:main Jun 3, 2026
9 checks passed
@lbarcziova lbarcziova deleted the rebuild-buildroot-check branch June 3, 2026 13:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants