Modularity support

[fila43]

Description

Currently, Ymir supports just RPMs. Let's take a closer look at modularity. I am proposing multiple steps to automate modular fixes and updates as much as possible:

1. Triage a ticket and determine the correct branch
2. Utilize scratch build / copr build
3. Prepare MR
4. Prepare an empty commit for the /modules namespace
5. Utilize module build
6. Prepare errata and attach build

In the first step, I would like to reach the third step from my TODO list. The rest of the items would be really useful given the lack of module support in the other pipeline tools.

Benefit

No response

Importance

No response

Workaround

• There is an existing workaround that can be used until this feature is implemented.

Participation

• I am willing to submit a pull request for this issue. (Packit team is happy to help!)

[TomasKorbar]

Lets do only enabling of module triage only in the first PR. It will be easier to review and merge and your changes will be isolated in the triage agent. After merge you can proceed to backport agent which actually files the MRs.

[fila43]

The first step for adding modular support has been proposed. PR #692 propagates the Jira issue summary into Ymir's internal structures, detects modular packages via the module:stream/component:Title summary pattern, and maps them to the correct branch name (stream-{module}-{stream}-rhel-{major}.{minor}.0). For now, modular tickets are detected and logged but not dispatched downstream.

In the next step, I would like to propose a commit to enable backporting/rebase for modular packages. From my understanding, Ymir uses the rpmbuild utility and builds the package in Copr. So for modular backporting/rebase the same approach can be used. The main change needed is extending parse_branch_name() in version_utils.py to recognize the modular branch format and extract the RHEL version from it. Once parsed, the existing branch_to_chroot() logic handles Copr chroot selection automatically, since the RHEL version is already embedded in the branch name. The rest of the build pipeline (rpmbuild → SRPM → Copr build) remains unchanged.

Additionally, I will verify that:

• clone_repository works correctly with modular branch names
• MR creation targets the correct modular branch

Both should work out of the box, as they use the target_branch value directly.

So I am proposing the following action items:

• Extend parse_branch_name() to handle stream--rhel- modular branch format
• Remove return None guard in determine_target_branch() to enable modular dispatch
• Verify clone_repository with modular branches
• Verify MR creation targets the correct modular branch
• Add unit tests for modular branch parsing and chroot resolution
• End-to-end test with a real, modular Jira ticket

Future Step

Once the individual package build works for modular packages, I would like to utilise Copr to build the entire module, not just individual packages. This would allow validating that the patched package integrates correctly with the rest of the module stream. The full module build would only be triggered after the individual patched package passes the build itself, keeping it as a secondary validation step. This will be added gradually in a follow-up.

@lbarcziova @TomasKorbar @TomasTomecek

[ppisar]

I'm not sure what tooling this enhancement is going to be based on. But just in case I have a notice for you: RHEL 11, comparing to RHEL 10 won't have libmodulemd, DNF4, and libdnf. And DNF5 and createrepo_c will be built without modularity support. I guess you are going to forward all building to Copr, so it's probably matter of Copr whether it will upgrade its infrastructure to RHEL 11, or not.

[TomasTomecek]

@ppisar thanks for the headsup! We'll keep that in mind when thinking about adding RHEL11 support in the future. We already have fragmentation in this regard that we parse specfiles in c9s and c10s environments respectively so this seems like 11 will be another such case