releng

#12303 Add critpath data for ELN
Closed: Fixed with Explanation by kevin. Opened by adamwill.

Closed: Fixed with Explanation
Reopen Issue
  • Describe the issue
    I've been asked to look into doing update testing and gating for ELN with openQA. To do this efficiently, it would be good to have critical path data for ELN (otherwise I'd have to run the tests on every ELN package).

I have written up the changes to critpath.py to do this properly, but that needs the critical paths to be defined in ELN comps data, which currently they aren't, and it's not as simple as copy/pasting them from Rawhide's comps as there's a wrinkle with the ELN data being in a slightly different format (with 'variant' stuff in it).

As an interim hack (famous last words...) I'm going to send a PR that notices when we're writing out the Rawhide files and copies them to the names for ELN. That should be good enough for now. If some of the packages that are critpath for Rawhide are not a part of ELN somehow, this shouldn't have any negative consequences for Bodhi (all Bodhi does is check the file when an update is created and see if any packages in the update are in the list, so having non-existent packages in it shouldn't matter much).

  • When do you need this? (YYYY/MM/DD)
    No specific date.

  • When is this no longer needed or useful? (YYYY/MM/DD)
    When ELN disappears or we change testing enough that we don't need the critpath definition any more.

  • If we cannot complete your request, what is the impact?
    It'll be less practical to implement testing and gating of ELN updates.

Tagging @sgallagh

https://pagure.io/releng/pull-request/12304 is the hack approach.

OK, so there's good news here. We don't need to specify the variant= field in the comps.xml, it just provides some hinting to pungi when we are splitting the comps contents up into the various BaseOS/AppStream/CRB repositories. If it's unspecified, it goes into the primary repository (BaseOS).

I verified this with the cloud-server comps.xml that I recently added, which doesn't have the variant bits.

So we could start with just copying the critpath entries directly from Rawhide comps.

So the thing I was worried about is, if we copy those groups in, and they happen to specify a package that's otherwise not in ELN, will they result in the package being added to ELN?

It will. That's how the tooling works for RHEL/CentOS too, and it's used to add stuff to the CRB repo.
Edited by ngompa

That's what I was afraid of. So we'd need to carefully compare the lists to what's actually in ELN if we go that route. :| Well, one good thing at least is we'd only really need a subset of the groups for ELN - if we initially just want to do the installability testing we only really need critical-path-base , critical-path-installer and critical-path-compose .

meanwhile, the hack is working so well that we invented KDE for ELN! https://bodhi.fedoraproject.org/updates/FEDORA-2024-cbed115e74 is in the critical-path-kde group :D

OK, that's funny, but it shouldn't really break anything. we can get fancier with the hack - instead of just copying the file, write a filtered version of the JSON for ELN - but I don't know if it's worthwhile, compared to just going ahead and doing it 'properly' by adding critpath groups to ELN comps.

It can't add packages to ELN that aren't already there. It could move packages that are supposed to be in AppStream or CRB into the BaseOS repo, which isn't great.

Metadata Update from @phsmoura:
- Issue tagged with: medium-gain, medium-trouble, ops

ok, lets go ahead and close this now that we have the 'hacky' version in.

ELN folks can add comps groups when/if they like (and can track that work in a eln tracker I would hope. ;)

Metadata Update from @kevin:
- Issue untagged with: medium-gain, medium-trouble, ops
- Issue close_status updated to: Fixed with Explanation
- Issue status updated to: Closed (was: Open)

Issue status updated to: Open (was: Closed)

Metadata Update from @phsmoura:
- Issue close_status updated to: Fixed (was: Fixed with Explanation)
- Issue tagged with: medium-gain, medium-trouble, ops

Metadata Update from @kevin:
- Issue close_status updated to: Fixed with Explanation
- Issue status updated to: Closed (was: Open)

https://pagure.io/releng/pull-request/12310 filters out the irrelevant groups for ELN.

Metadata Update from @adamwill:
- Issue untagged with: medium-gain, medium-trouble, ops
- Issue status updated to: Open (was: Closed)

That PR was merged. :)

Hopefully we are now good here. Feel free to re-open if there's anything else to do.

Metadata Update from @kevin:
- Issue close_status updated to: Fixed with Explanation
- Issue status updated to: Closed (was: Open)

No, it's fine. I didn't mean to re-open this, it's a Pagure bug.
Metadata
None
None
None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.