Add golang related CVE tickets rebuild agent for RHEL 9.x/10.x z-streams

[vnaruka]

TODO:

• Write new tests or update the old ones to cover new functionality.
• Update doc-strings where appropriate.
• Update or write new documentation in packit/packit.dev.

Notes -

Add a new golang CVE rebuild agent (ymir/agents/golang_rebuild/) that automates rebuilding
RHEL 9.x and 10.x z-stream components affected by Golang CVE fixes.

• What it does

  • Reads build instructions from Jira comments (side-tag, commit hash, extra Jira IDs, custom
    message)
  • Forks dist-git repo via MCP gateway (same as existing ymir agents)
  • Bumps spec file (release version + changelog) as `Golang Rebuild Agent
  • Updates %global commit0 and sources when commit hash is provided
  • Triggers scratch build (rhpkg scratch-build --srpm), supports side-tag targets
  • Posts scratch result to Jira, waits for golang-rebuild-approved label
  • On approval: commits, pushes to fork, opens GitLab MR for review
  • Official build happens when MR is merged via GitLab pipeline

• Changes to existing files

  • ymir/common/constants.py — added golang rebuild Redis queues, Jira labels, queue routing
    helper
  • ymir/common/version_utils.py — added 3 helper functions (get_branch_from_version,
    get_brew_target_from_version, get_short_version)

• New files

  • 14 source files + 5 test files + config + README under ymir/agents/golang_rebuild/
  • 63 unit tests
  • Full documentation in ymir/agents/golang_rebuild/README.md

• Developed with use of Claude AI.

Fixes

Related to

Merge before/after

RELEASE NOTES BEGIN

Added golang CVE rebuild agent for automating RHEL 9.x/10.x z-stream component rebuilds with
side-tag support, Jira comment-driven configuration, and GitLab MR workflow.

RELEASE NOTES END

[gemini-code-assist]

Code Review

This pull request introduces the Golang CVE Rebuild Agent, which automates rebuilding RHEL 9.x and 10.x z-stream components affected by Golang CVE fixes. The agent integrates with Jira for tracking and GitLab for merge requests, utilizing rhpkg and brew for build operations. The implementation includes a workflow orchestrator, a Brew client, a Jira query module, and a spec file parser. Feedback includes a recommendation to wrap Pydantic model validation in try-except blocks to handle malformed data from Redis and a suggestion to replace the deprecated callable type hint with collections.abc.Callable.

[lbarcziova]

Thanks a lot for the contribution!

Before diving into details - could you clarify the intended usage? From the CLI, local tool prerequisites in the README, and the approval gate design, this looks like it's primarily meant as a tool engineers run locally on their workstations. Is that right?

Asking because we've recently introduced a generic, service-based rebuild pipeline (ymir/agents/rebuild_agent.py, shared utilities in ymir/agents/tasks.py, specfile tools in
ymir/tools/unprivileged/specfile.py) that already handles golang dependency CVEs — e.g. https://gitlab.com/redhat/centos-stream/rpms/git-lfs/-/merge_requests/43. Depending on your intended use case, we'd want to figure out the right way to avoid duplicating work and build on what's already there.

A few things I noticed that overlap with what we have:

• Spec file handling - the new SpecFile class reimplements release bumping/changelog. Our existing UpdateReleaseTool handles %autorelease, Koji queries for z-stream release counters, etc.
• Git operations - I think we already have a lot of this covered in our tools
• Queue/model/subprocess code - we should try to reuse existing code here

I can see some genuinely new pieces that would be great additions:

• Scratch build pre-check - running a scratch build before creating the MR to catch failures early. We have been so far using Copr for verification for backports/rebases, although there have been some discussions to change this in future.
• Source update flow - updating %global commit0 + spectool -g + rhpkg new-sources for cases where the upstream source changes. Would require discussion if this should be configurable.

Could you have a look at the existing pipeline and the example MR? We'd be happy to meet and chat through this together (cc @opohorel who has been heavily involved in the current rebuild workflow). What do you think?

[vnaruka]

Hi Lbarcziova,

"From the CLI, local tool prerequisites in the README, and the approval gate design, this looks like it's primarily meant as a tool engineers run locally on their workstations." - This was for me to test in my environment, I will remove this thing. That's not the use case here.

Intended use cases I was looking for -
Create a agent that will be able to rebuild tickets related to golang, it should be able to use side-tags in builds, updating commit hash and sources files, do scratch builds and waits for user approval before going with MR, user will provide all required info in jira comment.

I see https://gitlab.com/redhat/centos-stream/rpms/git-lfs/-/merge_requests/43, This have most of the things I want, I will see to enhance existing use cases. Thanks for letting me know.