On 9/13/23 23:37, Carlos Rodriguez-Fernandez wrote: > Hi, > How will the SIG work with ci tests for EPEL packages? I was wondering > if those tests must be in one side (EPEL), or will be on both (EPEL&Int. > SIG 3rd Party services), or if there will be some point of integration > (e.g., some unified place for published results, etc...). I see EPEL > builds in bodhi but I'm not sure what the state of automated CI in EPEL > is in respect to CentOS Stream. Good question. It touches so many interesting topics at once :) For example, what does "being on the side" mean? When we run a test, we have multiple things: 1. content, the test scenario written by someone; 2. event, which triggers the test; 3. worker, which runs the test; 4. results, which are stored somewhere; 5. feedback, which is shown to someone; 6. decision, which is made based on test results. So who does what where? Let's consider the task: run a package build and a tmt test for it from a dist-git of an EPEL9 package minetest, on every update of the glibc package in the CentOS Stream 9. One possible implementation I have in mind would work as follows: ---- 1. content Content is stored in src.fedoraproject.org/rpms/<package name>:<epel9> and managed by the package maintainer of the EPEL branch 2. event Event is created by the CentOS Stream infrastructure (message or GitLab webhook) 3. worker Can be CentOS Stream Zuul CI. 4. results The long-term storage is probably not needed here, so the standard storage assigned by the worker with retention about a week will be enough. 5. feedback One part of the feedback should be provided to the EPEL maintainer of minetest - how? Another to the CentOS package maintainer of glibc. 6. decision Here the change happens on the CentOS Stream side, so decision to land or not to land a change is done by the CentOS package maintainer (Red Hat employee) ---- In this example the EPEL Project doesn't even have to participate in this work as a project. All of this can be implemented between the EPEL package maintainer and CentOS SIG. Yet as EPEL represents thousands of packages we probably don't want to handle each of them separately. Handling ownership changes alone would be a burden. Also ideally for every test we run on change in CentOS Stream we should run same test on change in EPEL. So we need to create some kind of relationship between EPEL and CentOS Stream Integration efforts so that EPEL CI and CentOS Stream Third-Party CI are working together. It may also be beneficial for EPEL to provide full control over CI workers to EPEL maintainers, therefore to not use the CentOS Stream CI for it, but rather introduce a different setup. I am not sure yet how exactly it will work in the end. But I see the purpose of the CentOS Integration SIG is to be the place where we can have this conversation. And I'd like to invite EPEL folks to it. -- Aleksandra Fedorova Matrix: @bookwar:fedora.im Fediverse: @bookwar at fosstodon.org