I wonder, if gating.yaml has this section:
Where is gating.yaml actually taken from? Is it the branch that is being gated,
or always master, or something else?
Why is the "product_version" not determined by the branch?
Thanks for clarifying.
Do we have any options for storage/access of the output of CI runs
other than the Jenkins UI?
It'd be nice to enable some sort of semi-permanent static links for
stuff like html-formatted output that some tools offer. I'm not sure
jenkins allows that without publishing to en external host but if I'm
mistaken here, pointers to links would be appreciated.
I'm currently working on a system to run rpminspect on every build
coming out of koji but will likely branch out and replace taskotron in
the not-so-distant future. As part of this, I have some questions about
the gating system and the other ci systems which feed it.
How does the gating system handle builds with missing results? As much
as I'd like to say that the new system will be perfect, I know better
and I hope that other folks do as well. When there are internal issues
which lead to missing results that the gating system is looking for,
how is this handled?
Is there anything that is looking for these missing results currently
or is it only addressed if/when brought up by packagers?
How are requests for re-running tests handled?
For the existing pipelines, how are test triggers cached or jobs
re-scheduled when there's downtime for the testing system?
I need to do the following on the PR pipeline:
1. dnf install mock (I know how)
2. mock -r fedora-rawhide-x86_64 init (should work)
3. mock -r fedora-rawhide-x86_64 <package_form_ci_koji_scratchbuild> (no idea)
4. various package builds in that mock (no problem)
Could you please help me with 3?
The package should be installed on the system so I might be able to salvage it
from the dnf cache, but I'm not sure if that it reliable.
I am interested in using Fedora CI to automate running integration tests
for the package I maintain https://github.com/Scribery/tlog in Fedora.
Currently, I am running all our integration tests manually/locally.
I understand that gating and tests can be run automatically when pull
requests are pushed to the fedora dist-git repositories
src.fedoraproject.org, but I was wondering if there is a way to trigger the
Fedora CI test run from the creation of a github Pull Request. Is it
possible to automatically sync a Github repository with a Fedora dist-git
repository to handle this?
This leads to another question that might help contextualize what i'm
looking for. Is Fedora CI intended to be used to test individual
commits(like in a single Github PR), or only multiple changes contained in
a Fedora-built package?
If this workflow automation is not possible, i'd like to know if package
maintainers are using a more efficient workflow than the following:
1) Submit PR to Github with new code changes
2) Build new SRPM with aforementioned changes
3) Submit PR to fedora CI dist-git repository to trigger tests
Thanks in advance.
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 , 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
** The first job runs a scratch build on Koji and shares artifacts (rpms)
with two child jobs.
** The first child job runs a rpm lint.
** The second child job runs the functional tests included in the package.
Here  you can see a PR where those Zuul jobs ran. More details can be
found here .
* 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  the
python-mock RPM from the dependent PR is used when building python-redis.
* 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 . More details can be found here .
We started that POC because we think Zuul offers a lot of useful features
 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.