Hi,
This is awesome! Looking forward meeting you on Flock to discuss where this
is going.
On Mon, Jul 1, 2019 at 2:53 PM Fabien Boucher <fboucher(a)redhat.com> wrote:
Hello,
I'm writing to this list to share about a proof of concept me and my team
are setting up. The goal of the POC is to show that Zuul, OpenStack's
code gating system [1], can be used to automate RPM-related jobs for
Fedora's CI.
We've managed to implement the following workflows:
* Run jobs when PRs are opened/changed on a Pagure instance. Recently Zuul
added support for Pagure events so we were able to set up some packaging
jobs on Zuul triggered by PRs on
src.fedoraproject.org. There are three
jobs attached:
** The first job runs a scratch build on Koji and shares artifacts (rpms)
with two child jobs.
Is this really build on Koji, or you build it in mock on your nodes?
https://fedora.softwarefactory-project.io/logs/5/5/616ac07a47e38483d6bbf6...
** The first child job runs a rpm lint.
** The second child job runs the functional tests included in the package.
Here [2] you can see a PR where those Zuul jobs ran. More details can be
found here [3].
* Run jobs when PRs are opened/changed that depend on others PRs. A
packager is able to tell Zuul that a PR depends on others PRs by using
the "Depends-On:" keyword in the PR's initial message. The artifacts from
dependent PRs are available on a PR's job's workspace as well; in [4] the
python-mock RPM from the dependent PR is used when building python-redis.
Very cool feature! I am glad to see Zuul support for Pagure.
* Run jobs when a package is built on Koji. The idea is to listen to the
fedmsg queue, waiting for the topic "buildsys.build.state.change", run
the configured Zuul jobs, and finally publish the jobs' results on
fedmsg. At the moment we are able to run a linter job each time a package
is built, but we don't publish the results on fedmsg. Here is the list of the
most recent linter job results [5]. More details can be found here [6].
Zuul-gateway seems to be quite a workaround, is the long term plan to
change to support event based triggers "directly" ?
We started that POC because we think Zuul offers a lot of useful
features
[1] like handling PR dependencies that could be of interest to the Fedora
project. The POC has shown some working workflows but now we need
insights from people who know what the needs of Fedora's CI are. Let us
know your thoughts, and we will be happy to extend the POC and onboard anybody
wanting to experiment with Zuul in that context.
My Testing Farm team would like to experiment using Zuul for our workflows.
Does Nodepool support prioritization of different drivers? We would like to
offload some of our workloads to AWS in case of spikes, but would like to
use it only if non-paid resources (Openstack, Openshift) had been exhausted.
How is the driver selected for a job? Our testing jobs describe an
environment which we would like the CI system to translate to a specific
driver, according to an predefined priority.
How hard would it be to support non-Ansible based jobs please?
Thanks,
/M
--
Miroslav Vadkerti :: Principal QE :: Testing Farm / BaseOS QE / OSCI
IRC mvadkert #tft #osci #qe :: GPG 0x7B5B2E95
TPB-C 2C215 :: Mobile +420 773 944 252
Red Hat Czech s.r.o, Purkyňova 115, 612 00, Brno, CR