[CentOS-devel] Let's setup the CentOS Integration SIG

Wed Sep 20 18:10:07 UTC 2023
Carlos Rodriguez-Fernandez <carlosrodrifernandez at gmail.com>

Thank you so much Aleksandra for the detailed response.

On 9/20/23 06:31, Aleksandra Fedorova wrote:
> 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.
> 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x47EBED05C3375B1F.asc
Type: application/pgp-keys
Size: 2484 bytes
Desc: OpenPGP public key
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20230920/5374fbfa/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 665 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20230920/5374fbfa/attachment.sig>