Feat: Add utility function for getting previous errata

[Jazzcort]

This utility function finds the previous errata with given errata ID (current)
and package name. The output will be a errata with the closest RHEL release
version. Here we pick REL_PREP over SHIPPED_ALIVE.

[gemini-code-assist]

Code Review

This pull request introduces a utility function, get_previous_erratum, to find a preceding erratum based on a set of criteria. The implementation correctly adds new data classes for RHEL versions and streams, which improves type safety and code clarity. However, the review identified some critical issues related to code robustness and performance. The current implementation makes unsafe assumptions about API response structures, which could lead to runtime errors if dictionaries or lists are empty. Additionally, there is a significant performance concern due to API calls being made inside a loop. The detailed comments below provide specific suggestions to address these issues.

[Jazzcort]

Mark two things for advice. 😄

[owtaylor]

Good work figuring out the APIs and coming up with something! I'm a bit worried about the performance of your solution - there can be a lot of errata for a package and having to loop through and list all their builds could be quite slow and resource intensive. Also, having to take an arbitrary RHEL product version string and parse it into something comparable to another is hard - how does RHEL-8.8.0.Z.EUS.EXTENSION compare to RHEL-8.8.0.Z.AUS?

So I tried to come up with something a little different - but wow this is so complex - I spent hours digging through the erratatool API docs and sources to try and understand how everything relates. 😅 .

One of the complexities is "Product Version" vs. "Release" - for RHEL 8/9/10, the are almost identical - there's a RHEL-10 product version, but no release, there's a RHEL-8.4.1.Z.MAIN release but no product version, and a handful more differences like that, but in general, a RHEL-10.0.Z product version is 1:1 withthe RHEL-10.0.Z release. We can assume that.

[As I understand it, the basic idea of the split is that a layered product might have a single release that ships packages that work on top of multiple versions of RHEL - so it would have separate product versions for "1.2 release of layered product for rhel 8" and "1.2 release of layered product for rhel 9"]

Another thing is "ReleasedBuild" records. They are almost impossible to find in the UI, but they are maintained (externally in some fashion from erratatool) to keep track of what is shipping in each product version. So I can:

$ curl -u : --negotiate 'https://errata.engineering.redhat.com/api/v1/product_versions/RHEL-10.0.Z/released_builds/glib2' | jq
{
  "build": "glib2-2.80.4-4.###el10_0.6",
  "errata_id": 152126,
  "created_at": "2024-08-27T05:57:05Z",
  "updated_at": "2025-07-14T08:38:23Z"
}

the twist here is that for unreleased releases, records exist, but they are wrong.

The 90% solution

1. Start with a pair of a errata and the package within the errata that you want to check [errata can have multiple packages]
2. Get the release of the errata and use the erratatool api to find out the the ship_date and use that to determine whether the release is released.
3. If the release is released, use the released_builds API to find out the released build for package and the matching product version
4. If the release is not released, determine out the predecessor z-stream. product version, and use the released builds API to get the build for that
   • RHEL-10 - it's RHEL-10.<y-1>.Z
   • RHEL 8 and 9 - it's RHEL-x.<y-1>.0.Z.MAIN if y-1 is odd, RHEL-x.<y-1>.0.Z.MAIN+EUS if y-1 is even.
     (Early in RHEL 8 there were quarterly update product versions like RHEL-8.3.1.Z.MAIN, but we don't have to worry about them any more - the predecessor z-stream for an unreleased release will not be that old.)

Pending REL_PREP errata?

The above accomplishes the original goal of finding the relevant "SHIPPED_LIVE" errata for the package, but do we want to also consider errata in REL_PREP that will be released before this erratum?

• For the same release, in an earlier batch
• For an earlier release - either the GA release for a Z stream, or the predecessor Z-stream as defined above

The way we would implement that:

• Use the relationships.errata part of the /packages API to find all the errata for the package as you did in your patch, but consider only the REL_PREP ones.
• Get the data for each REL_PREP errata, check in order of priority for:
  1. Errata for the same target release
  2. For unreleased z stream target releases: errata for the corresponding GA release
  3. For unreleased z-stream and GA target releases: errata for the predecessor z-stream release with a publish_date before the ship date of the unreleased release
     Once we find any errata in any of these categories, use the one with the latest publish_date and stop there. If we don't find any, fall back to the solution above.

We don't need to list the builds - we know that one exists for this package - we can just look at the release for the errata.

Note: I don't think we ever need to look at previous major versions - there will always be a package for the same major version, unless we're working on a new version of RHEL, which is not in scope at the moment.

[Jazzcort]

RHEL-10 - it's RHEL-10.<y-1>.Z

@owtaylor Just a quick question. Do we check RHEL-10.<y-1>.GA or RHEL-10.<y-1>.Y before we check for RHEL-10.<y-2>.Z?

[owtaylor]

We dopnm

@owtaylor Just a quick question. Do we check RHEL-10.<y-1>.GA or RHEL-10.<y-1>.Y before we check for RHEL-10.<y-2>.Z?

Before RHEL-10.y is released publically, both RHEL-10.y is released both RHEL-10.y.GA and RHEL-10.y.Z will be unreleased, so the predecessor release of them is RHEL-10.<y-1>.Z

Normally, that will be released. The only case I can think of where it would not be released would be someone getting an early start on y-stream (RHEL-10.<y>.GA) before RHEL-10. is released. I guess to handle this case, if we pick RHEL-10.<y-1>.Z as the predecessor release and it's also unreleased, we fall back to RHEL-10.<y-2>.Z We never should pick a GA as a predecessor release since the Z-stream and the GA are released at the same time, typically with errata already on the Z stream (0-day errata).

[owtaylor]

Definitely getting there! a bunch of mostly style suggestions

[Jazzcort]

Thanks for the review! Working on it!

[owtaylor]

It looks quite functional at this point - the comments below are mostly just trying to figure out how to make things more readable and maintainable for the future.

[owtaylor]

I'd end it with \.([^\d].+)$ what you have turns "Z.AUS" into "Z" because it doesn't anchor at the end, which might be intentional but is confusing. Let's say that if it returns non-null, then str(RHELVersion.from_str(s)) must be s. In fact, add an assertion to this effect at the end of this function.

[Jazzcort]

I change it to \.([^\d].*)$ because \.([^\d].+)$ can not catch the version string with one character stream (i.e. RHEL-10.1.Z).

[owtaylor]

Looks good to me, needs a doc comment for the new function. Once you do that, can you trigger a re-review from Gemini with gemini review ? It might find a few things.

[Jazzcort]

Planing to add docstring tmrw. Will triger a gemini review after that! Let's see what it'll find!

[Jazzcort]

/gemini review

[gemini-code-assist]

Code Review

This pull request introduces a new utility function to find the previous erratum for a package, which is a valuable addition. The implementation includes new data models for RHEL versions and releases, and logic to traverse the release history.

My review has identified a few areas for improvement:

• A critical bug that could cause a runtime TypeError when searching for the latest erratum.
• A potential performance bottleneck due to multiple API calls within a loop.
• Some correctness issues related to return types and discrepancies between the implementation and the feature description.
• Minor suggestions for improving testability and robustness.

Please see the detailed comments for specific suggestions.

[Jazzcort]

@owtaylor In the previous comment-style review, gemini mentioned we can make get_RHEL_release a cache function. I think it's a good suggestion because the result of release API should not be changed frequently.

[owtaylor]

@owtaylor In the previous comment-style review, gemini mentioned we can make get_RHEL_release a cache function. I think it's a good suggestion because the result of release API should not be changed frequently.

When I reviewed my thought process on this was:

• This seems cachable
• But we shouldn't cache indefinitely, because what if the release's publish date or something changes
• We could use the cache_async decorator from qe_data.py - but that's specialized for async.... so something new would need to be written
• How often is it that multiple REL_PREP errata are pending for the same release? Not worth the bother...

I'll stand by by that thinking :-)

[Jazzcort]

@owtaylor Could you give it a quick overlook? I think it's ready to be merged! 😁

[owtaylor]

One editing suggestion, otherwise looks great and is ready merge.

[Jazzcort]

Thanks for the review!! 😁