CI July 2019

ci@lists.fedoraproject.org

11 participants
7 discussions

Where is gating.yaml fetched from? How does the branch relate to product_versions?
by Miro Hrončok 30 Jul '19

30 Jul '19

I wonder, if gating.yaml has this section: product_versions: - fedora-* 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. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

3 4

Storage and access of test logs/output
by Tim Flink 19 Jul '19

19 Jul '19

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. Tim

2 3

Gating and availability of result data
by Tim Flink 16 Jul '19

16 Jul '19

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? Thanks, Tim

3 2

PR pipeline: install the package to mock
by Miro Hrončok 03 Jul '19

03 Jul '19

Hey CIers! 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. Thanks, -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

2 3

Cancelled Fedora CI SIG meeting today (July 3, 2019)
by Aleksandra Fedorova 03 Jul '19

03 Jul '19

Hi, all, due to coming holidays and PTO's let's cancel the meeting today. Please take a look and provide feedback on Zuul pipelines mail [1] Next meeting is on 17 July 2019[2]. We will discuss Flock agenda and schedule and status reports. [1] https://lists.fedoraproject.org/archives/list/ci@lists.fedoraproject.org/th… [2] https://apps.fedoraproject.org/calendar/SIGs/2019/6/5/#m9549

1 0

Integrating Fedora CI with github project
by Justin Stephenson 02 Jul '19

02 Jul '19

Hello, 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. -Justin

2 1

Experiments with Zuul CI
by Fabien Boucher 02 Jul '19

02 Jul '19

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. ** 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. * 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]. 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. Regards, Fabien Boucher [1] https://fedoraproject.org/wiki/Zuul-based-ci#What_is_Zuul [2] https://src.fedoraproject.org/rpms/python-gear/pull-request/5 [3] https://fedoraproject.org/wiki/Zuul-based-ci#Pagure_PR_tests_via_Zuul [4] https://stg.pagure.io/python-redis-distgit/pull-request/1 [5] https://fedora.softwarefactory-project.io/zuul/t/fedora-staging/builds?job_… [6] https://fedoraproject.org/wiki/Zuul-based-ci#Buildsys_build_validation_via_…

3 6

2024

2023

2022

2021

2020

2019

2018

2017

CI July 2019