On Wed, Jan 24, 2024 at 4:29 AM Tomas Kopecek <tkopecek(a)redhat.com> wrote:
Koji 1.34.0 is out. As usual - Thanks to everyone who contributed!
There was a bigger gap between releases in this cycle, but we hope we will return to
regular cadency with the next release. On the other hand, there is a good reason for this,
so we can introduce two big changes.
First one is that we've restructured the scheduler and moved its logic to the hub
from the builders. It should be mostly invisible to the users. Probably the only place
where you can hit it are large queues which will not impact the whole koji performance.
But that was probably the most tricky part before we can incrementally introduce further
enhancements such as policies with multiple outcomes and starting to dismantle the
channel/pool system for the builders. In the future build could request specific resources
instead of being started in the predefined channel.
This is a big step to getting towards OBS-style per-package
constraints for selecting build environments. That's huge!
Second big thing which is way more visible are Draft builds. This is
the concept which fills the gap between scratch and regular builds. Draft builds ARE
regular builds which have NVRs (their release part) slightly modified, so it is possible
to have multiple builds from one spec file version. When It is decided which of these
variants is valid (passes tests, release policies, etc.) it will be "promoted"
to NVR with unmodified release and will become the only valid build for the NVR.
In theory, could we use this as part of being able to do something
like Koschei[1] except with real builds? One of the biggest crap tasks
we have in Fedora is having to manually work out reverse dependencies
and rebuild them when a library is being upgraded. It almost always
requires provenpackager help, which should be unnecessary. It punishes
contributors for packaging something popular when they can't do
maintenance because they don't have the power to fix their consumers.
Admittedly, even if it does, we still need some kind of way to emit a
build counter from Koji of the number of times a specific SCM or SRPM
was successfully built in Koji for a build to consume and expose in
the environment to use as a property to make builds unique...
[1]:
https://koschei.fedoraproject.org/
--
真実はいつも一つ!/ Always, there's only one truth!