On Mon, Feb 20, 2017 at 11:26:00PM -0800, Adam Williamson wrote:
On Tue, 2017-02-21 at 07:43 +0100, Pavel Raiskup wrote:
> On Monday, February 20, 2017 6:44:50 PM CET Jan Kurik wrote:
> > Fedora will no longer produce Alpha releases.
> As a side-effect of making rawhide "alpha". That doesn't sound bad.
> After seeing Denis's talk on devconf, I think I understand the motivation:
> it takes ages to generate all the Fedora related products like images.
Well, yes, it does, but that's not so much a *motivation* for this as
one of the factors that complicates the implementation. The motivation
is simply to have a better quality product.
> > == Detailed Description ==
> > By gating Rawhide builds from landing in the compose and gating the
> > publication of composes on automated test results we will ensure Rawhide will
> > always be at Alpha quality. This will make it more generally useful to people
> > as a daily driver and development platform, and mean we no longer need to go
> > through the process of building, testing and shipping Alpha releases. The
> > initial testing will be ensuring that a package is installable and that it
> > does not break existing packages installation.
> Ok, I'm curious why we'll treat CI/testing differently on stable releases
> and on fedora. AFAIK, _bodhi_ runs the tests for stable releases, and for
> Rawhide it will be koji directly? Why you don't move all the testing to koji
Neither Bodhi nor Koji runs any tests (except for the %check section of
a package build, I guess). The package tests are run by Taskotron.
Right now they are run for every Koji build, but adjusting the triggers
is fairly trivial, if we want to trigger the tests in any other way.
You can see the trigger code at
You can *see* the test results from the Bodhi web interface, but that
doesn't mean Bodhi is running the tests or really that the tests have
querying ResultsDB for any test results marked as being related to the
packages in the update. (Out of interest, if I manage to get my current
side project of having openQA run tests on critpath updates up and
running, those results will just 'magically' show up in Bodhi as well,
since all Bodhi is doing is querying ResultsDB).
But ResultDB does not have an UI people are used to to get information about new
update, while Bodhi does.
This is exactly why I think we should gate rawhide update in bodhi, we need a
place to provide feedback to the packagers about why an update went through into
rawhide or why it didn't.
Bodhi even offers the possibility to edit and group updates then.
The whole CI workflow relies on the possibility to give and receive feedback, so
we need a place to do that. FMN is one, but in itself it is not sufficient,
people don't necessarily use it, ignore it, delete the notifications and it is
not public. If you build and update and for some reason I end up two days later
wondering why it didn't hit rawhide, I need a place to go and have this info.
ResultDB isn't this place.
Bodhi on the other hand is public and stable. Anyone can access it and see why
an update wasn't pushed (because tests Y and Z failed) and for the packagers
they know they can always find back this information there.
> It is not specified, but there will be two sets of tests? One
> move the package to buildroot to build against, and second to move the
> package to rawhide repo, right? Then what about to do apply the same
> process for updates-testing?
There are already quite a lot of plans in place relating to this. Bodhi
is only one possible integration point for tests. The major focus at
present is to deploy a Pagure instance on top of dist-git, as that
provides another point at which we can provide a proper test feedback
loop. Right now, we already run package tests on every Koji build and
we could in theory run package tests on every git commit (as we know
when dist-git commits happen), but there is no system through which can
do any kind of useful feedback loop or gating based on the results.
Pagure-for-dist-git would provide that.
Pagure would provide this at the package leve, Bodhi could do it at the update
Actually, pagure should be offering feedback *before* the merge has occurred and
the package even been built in Fedora, while bodhi will provide feedback *after*
it was built but *before* it is pushed.
I really believe we ought to gate update in bodhi, just with the tooling to
automatically push them as the test results are returned.
Similarly, we should provide feedback on pagure for each PR offering a change to
a spec file.