On Mon, Sep 12, 2022 at 10:22 AM Leon Fauster via CentOS-devel < centos-devel@centos.org> wrote:
Am 12.09.22 um 16:47 schrieb Troy Dawson:
On Sun, Sep 11, 2022 at 2:05 AM Phil Perry <pperry@elrepo.org mailto:pperry@elrepo.org> wrote:
On 11/09/2022 08:41, Branislav Náter wrote: > Hi, > > > On Sat, Sep 10, 2022 at 8:46 PM Leon Fauster via CentOS-devel > <centos-devel@centos.org <mailto:centos-devel@centos.org> <mailto:centos-devel@centos.org <mailto:centos-devel@centos.org>>> wrote: > > I wonder about the current firefox build 91.13.0-1.el9? Its not on the > mirrors (comp 20220829) nor in the last prod compose (20220909) / both > lists firefox-91.11.0-2.el9 ... Thanks. > > > For inclusion in the compose, it has to pass testing. Testing is still > in progress. > > I'm just trying to understand how it can still be in testing forStream
when it has clearly passed testing and been released to RHEL? Ithought
Stream sat 'upstream' of RHEL? What extra testing is performed for packages in Stream that is not performed for the same packages in RHEL? What tests are failing?Should
we be concerned as RHEL users that we are not receiving the full testing experience?So people know the sequence of events.
firefox-91.13.0-1.el9_0 was built in RHEL 9.0 on 2022-08-18
- The build passed all of it's gating tests.
- This was built on a RHEL 9.0 buildroot, and tested on a RHEL 9.0
buildroot
- This got pushed to RHEL 9.0 only
firefox-91.13.0-1.el9 was built on CentOS Stream 9 and RHEL 9.1 on 2022-08-25
- This build did not pass it's gating tests - it still hasn't
- This was built on a RHEL 9.1 buildroot, and tested on a RHEL 9.1
buildroot
- As far as I can tell, it's got the same tests. It's possible that one
or more of the tests went from "warn when it fails" to "fail when it fails", but it looks like the tests are the same.
- It's also possible that something changed in RHEL 9.1 that is causing
the tests to fail.
- I'm not on the firefox team, I'm just looking at the gating system,
and to be honest, when I look beyond the "passed" - "failed" parts and into the results, I get lost.
From everything I can see, this delay wasn't the result of an embargo, simply tests not passing.
I had the understanding that those gates are responsible to sync between RHEL/CENTOS build pipelines? Especially for the major version 9 this should be the state or do I misunderstand the workflow?
-- Leon
Since I don't exactly know what you are picturing as a workflow, I'll step through an average package update on RHEL9.
1 - maintainer (or others) create a merge request into CentOS Stream 9 gitlab area. 2 - the merge request is gated and tested before being merged. 3 - When that merge request gets merged in the Stream 9 gitlab area, it is also synced over to the internal Brew dist-git area. 4 - The maintainer starts the build in CentOS Stream 9. 5 - When that happens, a build starts on the internal Brew systems. 6 - When both builds finish, they are both gated. The testing only happens internally on the Brew build. 7 - When the internal testing passes successfully, then both RHEL and CS builds are moved on. 8 - Internally, an errata is made, or an errata is updated with the new build, and both packages move to -pending. 9 - Composes are created out of the -pending packages.
Early on there was talk about putting gating between CS and RHEL, but that would make the build repo's different, and eventually the CentOS Stream and RHEL builds would diverge.
I've simplified the steps some, and it's possible I didn't explain everything correctly. So if you need me (or others) to explain or expand on some of the steps, let me know.
Troy