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. > Right? 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 > then? 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 https://pagure.io/taskotron/taskotron-trigger/blob/develop/f/jobtriggers . 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 anything to do with Bodhi. That's just Bodhi's client-side Javascript 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). > It is not specified, but there will be two sets of tests? One to even > 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. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
