On Wed, 2019-11-20 at 08:57 +0100, Michal Srb wrote:
> Hello,
>
> On Tue, Nov 19, 2019 at 8:07 PM Adam Williamson <adamwill@fedoraproject.org>
> wrote:
>
> > On Wed, 2019-11-13 at 10:17 +0100, Fabien Boucher wrote:
> > > Hello,
> > >
> > > I would like to introduce a CI/CD workflow for Fedora distgits around
> > > Pull Requests my team and I have started to develop.
> >
> > Are the results of these tests reported to resultsdb? Does this flow
> > publish messages to fedora-messaging or fedmsg? Are either of those
> > things done in ways that are compatible with the several existing
> > implementations of "test stuff for a Fedora build/update/compose"
> > (Taskotron, "the pipeline", openQA, autocloud...)
> >
>
> Just curious, is the whole "test stuff for a Fedora build/update/compose
> ..." documented somewhere?
It's all documented *somewhere*, but there isn't exactly a central Here
Are All The Things That Test Stuff, mainly because there isn't really a
central team or plan or vision or anything. 'Fedora CI' is one thing
run by one bunch of people, Taskotron and openQA are both run by Fedora
QA (so we do have some pages which cover both and the relation between
them), autocloud was maintained by someone else and is now not really
maintained by anyone, and now this thing seems to have come along from
yet another bunch of folks...
To clarify, we (as "Fedora CI" group) and Zuul team have aligned our goals at Flock: Zuul team takes the task of pull requests verification and pre-merge check, while Fedora CI focus is the Gating and tests which triggered on builds in Koji after the merge to dist-git.
Unlike conventional CI systems, Zuul is much better integrated with the code review process. For example Zuul can manage dependent pull requests across different projects, even different Git Forges, or can provide merging and promotion actions, which our current CI implementation does not support.
We'd like to give Fedora community a chance to use this advanced system and provide feedback on it. And hopefully it will increase the adoption of pull-requests in the packager workflow.
Since our post-merge infrastructure and workflows are much more complex, we go there with the custom system (Bodhi, Greenwave, ResultsDB..) and continue our work in that direction. Zuul initiative is independent from it (at least for now).
We don't want to duplicate the content of our tests though. That's why we agreed on aligning our test interfaces. For example, Zuul pipeline supports dist-git tests (STI) and runs them the same way as Fedora CI does.
It maybe a good idea to align the interface for generic tests as well. Something we should research, probably.
--