On Wed, 2022-07-13 at 15:38 +0000, Mattia Verga via devel wrote:
Bodhi is a nice interface to create multi-builds update from
side-tags,
but it is not really optimized for massive updates. In the past we had
some troubles pushing updates with a lot of builds. There are too many
things done in the background that can break while processing a massive
update and making Bodhi more reliable is not so simple.
I wonder if it would be safe to set a cap to the number of builds a
single Bodhi update can carry. I think **really** massive updates (say
more than 99 builds?) should be handled manually asking Releng to merge
the side-tag manually.
I'd like to hear someone else opinion, especially from FESCo and Releng
members. Meanwhile I'll keep an eye on the recent massive Golang update
(which carries 315 builds...) to see if it shows any hiccups. (I'm quite
surprised it didn't screw up already)
Well, one awkward thing about this is that Bodhi is where we've
implemented quite a lot of CI/test automation integration. Fedora CI
runs tests at the package build level, but the results are primarily
shown - and gating is potentially done - at the Bodhi update level.
openQA runs tests at the Bodhi update level; if there isn't an update,
it will not automatically run tests.
It's also where we usually route *manual* testing feedback. If people
can't comment and karma a Bodhi update, where can they test this big
and very-potentially-destabilizing change?
99+-package updates are exactly the kind of case where we'd *want* to
consider automated test results before deciding to merge, usually.
If Bodhi can't be improved to handle this, I'd really want the
alternative path to have proper consideration for integrating test
feedback, both manual and automated.
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net