On Fri, Jul 10, 2026 at 07:11:38PM +0100, Adam Williamson wrote: > On Fri, 2026-07-10 at 18:21 +0100, Michel Lind wrote: > > One tweak to this - can we force a re-run before promoting a package > > from testing->stable as well, because as the example above showed (this > > is the rpki 0.19.3-1 update vs the quick-xml 0.41 update, FWIW) - > > testing once might not be enough as the state might have changed in > > subsequent composes? > > It's not trivial to do that, unfortunately, no. I don't think we need > to solve that to implement the initial gating, though. > > The way we actually do "promotion" for stable releases is that, once a > day (usually, IIRC), a Bodhi task running on a timer tags all updates > queued for stable at the time, assuming some other last-minute sanity > checks pass. (Then there's a compose which causes the tagged packages > to actually get sent out; I don't recall if that's part of the same > process, or a separate one).
My memory could be faulty, but I don't think thats how it's setup. There's a celery task that runs every ~5min and checks all the updates to see if they met stable requirements, if they have it adds the request to stable for them. Then, once a day there's composes that actually process those requests. > We *could* add a run of rmdepcheck to that process, I guess, but we'd > either have to set up a whole new messaging flow to get the existing > rmdepcheck pipeline to run it, or set up a new pipeline within the > Bodhi task, I think. > > I don't believe there's currently a flow where that process sends a > message saying it's about to push things stable then can wait for > external systems to Do Stuff and get their results before *actually* > pushing stable, we'd have to build that. Yeah, there isn't 100%, but there is a 'bodhi submitted update for stable'. That could of course happen 1minute before the daily compose and there would be no time, but the rest of the day that would be an indicator that it's going stable (probibly). > Or else we'd have to wire a run of rmdepcheck inside of the Bodhi task > itself, but that's also some work. > > Either way is also more complicated if we want to do anything more > complex then a straight up/down vote on the *entire set* of queued > packages. Say we run rmdepcheck on the whole set of packages about to > be pushed and it fails; are we OK with not pushing any of them? If not, > we need to figure out (I guess) the largest set of the candidate > packages that can be pushed without a failure, but that's not really > trivial and could involve a lot of re-runs, depending on how many > packages are queued... yeah, could be a big problem indeed. kevin -- _______________________________________________ devel mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected] Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
