Stop publishing .ci. messages?

adamwill commented

2026-06-09 17:50:13 +00:00

Owner

We currently publish various .ci. messages - the ones with a schema documented at https://forge.fedoraproject.org/ci/messages . For Fedora CI, the pipelines do this using the sendMessage function provided by https://github.com/fedora-ci/jenkins-pipeline-library . For openQA we have a plugin in the package which subclasses openQA's built-in AMQP plugin and makes it send CI Messages-format messages as well as its native messages.

The thing is...we don't really need these messages. This whole system was designed to be consistent with usage in CentOS and RHEL, but they are now moving away to pull request-based testing and AFAICT consider this whole setup to be "legacy". In Fedora-land, best as I can tell, there are only two things listening to .ci. messages:

There is also a consumer in Bodhi, but I'm fairly sure it is currently disabled, and it's redundant; I've sent a PR to remove it.

ci-resultsdb-listener converts messages to resultsdb results and submits them to resultsdb. I propose we should simply have the pipelines submit results to resultsdb directly: swap the "message sending" code out for "resultsdb reporting" code. The net complexity in the pipelines would be about the same, but we could get rid of ci-resultsdb-listener entirely, so overall things get simpler. We could also possibly get rid of the ci/messages repo if nobody else wants it for anything.

For openQA we could simply ditch the plugin, which would be great for me, I wouldn't have to make sure it works at every openQA upgrade any more.

resultsdb already publishes messages for each submitted result, so the ci messages are really pretty redundant: we send a message mainly to have it turned into a result, which...triggers a message.

For the containertools openqa-listener, it should be pretty easy to just have it use resultsdb messages instead of ci messages. The thing it's doing is pretty simple. I will file a ticket on it, and if we go ahead with this plan, I can probably find the time to update/enhance that listener to do exactly what @luap99 wants it to do.

CC @kevin @msrb @mvadkert for thoughts. If there's anyone else RH-y who might have thoughts on this please add them!

We currently publish various .ci. messages - the ones with a schema documented at https://forge.fedoraproject.org/ci/messages . For Fedora CI, the pipelines do this using the `sendMessage` function provided by https://github.com/fedora-ci/jenkins-pipeline-library . For openQA we have a [plugin in the package](https://src.fedoraproject.org/rpms/openqa/blob/rawhide/f/FedoraMessaging.pm) which subclasses openQA's built-in AMQP plugin and makes it send CI Messages-format messages as well as its native messages. The thing is...we don't really *need* these messages. This whole system was designed to be consistent with usage in CentOS and RHEL, but they are now moving away to pull request-based testing and AFAICT consider this whole setup to be "legacy". In Fedora-land, best as I can tell, there are only two things *listening* to .ci. messages: 1. https://forge.fedoraproject.org/apps/ci-resultsdb-listener 2. https://github.com/Luap99/containertools/tree/main/openqa-listener There is also [a consumer in Bodhi](https://github.com/fedora-infra/bodhi/blob/be7fc70c91a4e8f108c9d68360695443a2addcf0/bodhi-server/bodhi/server/consumers/ci.py), but I'm fairly sure it is currently disabled, and it's redundant; I've sent a [PR to remove it](https://github.com/fedora-infra/bodhi/pull/6123). ci-resultsdb-listener converts messages to resultsdb results and submits them to resultsdb. I propose we should simply have the pipelines submit results to resultsdb directly: swap the "message sending" code out for "resultsdb reporting" code. The net complexity in the pipelines would be about the same, but we could get rid of ci-resultsdb-listener entirely, so overall things get simpler. We could also possibly get rid of the ci/messages repo if nobody else wants it for anything. For openQA we could simply ditch the plugin, which would be great for me, I wouldn't have to make sure it works at every openQA upgrade any more. resultsdb already [publishes messages for each submitted result](https://apps.fedoraproject.org/datagrepper/raw?category=resultsdb&delta=172800), so the ci messages are really pretty redundant: we send a message mainly to have it turned into a result, which...triggers a message. For the containertools openqa-listener, it should be pretty easy to just have it use resultsdb messages instead of ci messages. The thing it's doing is pretty simple. I will file a ticket on it, and if we go ahead with this plan, I can probably find the time to update/enhance that listener to do exactly what @luap99 wants it to do. CC @kevin @msrb @mvadkert for thoughts. If there's anyone else RH-y who might have thoughts on this please add them!

👍 2

adamwill commented

2026-06-09 17:59:59 +00:00

Author

Owner

Issue for containertools.

[Issue for containertools](https://github.com/Luap99/containertools/issues/1).

adamwill referenced this issue

2026-06-09 21:05:08 +00:00

rmdepcheck: publish messages (and hence report results) by update #561

lecris added a new dependency

2026-06-10 10:02:35 +00:00

#561 rmdepcheck: publish messages (and hence report results) by update

lecris added this to the Board project

2026-06-10 10:15:27 +00:00

lecris commented

2026-06-10 10:27:30 +00:00

Owner

The only place that I think could be useful is if testing-farm would be publishing those and/or these would be consumed by a dashboard. But that's probably just wishful thinking, and we could just bring it back in a more modern home either under packit or toddlers?

The only place that comes to mind for me is https://github.com/fedora-ci/ciboard, which apparently got fixed and was being used by someone? @mvadkert made an announcement about it a while back

The only place that I think could be useful is if testing-farm would be publishing those and/or these would be consumed by a dashboard. But that's probably just wishful thinking, and we could just bring it back in a more modern home either under packit or toddlers? The only place that comes to mind for me is https://github.com/fedora-ci/ciboard, which apparently got fixed and was being used by someone? @mvadkert made an announcement about it a while back

mvadkert was assigned by lecris

2026-06-10 10:27:40 +00:00

msrb was assigned by lecris

2026-06-10 10:27:40 +00:00

lecris added the

labels

2026-06-10 10:28:22 +00:00

adamwill commented

2026-06-10 15:12:18 +00:00

Author

Owner

I mean, on the face of it, I think any idea that could use the .ci. messages could also just use resultsdb.result.new messages. They're published for every result and contain all the data in the result, and we control our own result submission, so effectively they can contain whatever we want them to. Heck, we could precisely re-create the entire ci message schema inside the result extradata if we wanted (let's not, though).

I don't think Fedora ever had a CI Dashboard instance? I think that announcement you're remembering was internal; IIRC, the internal instance was initially going to be retired, lots of people complained, then Miro announced it was back because someone was going to maintain it. Wherever that's happening, though, it doesn't appear to be in that GitHub repo, which since July 2023 has only had one small change in April 2024 and one small change in October 2025.

The original announcement says (I think it's safe to post this small snippet publicly):

You would normally use it to:

see which required tests need attention
check the results of unsatisfied tests
wave a failed test

For Fedora, all those functions are fulfilled by Bodhi, so I'm not sure the dashboard would be terribly useful.

I mean, on the face of it, I think any idea that *could* use the .ci. messages could *also* just use [resultsdb.result.new messages](https://apps.fedoraproject.org/datagrepper/raw?category=resultsdb&delta=172800). They're published for every result and contain all the data in the result, and we control our own result submission, so effectively they can contain whatever we want them to. Heck, we could precisely re-create the entire ci message schema inside the result extradata if we wanted (let's not, though). I don't *think* Fedora ever had a CI Dashboard instance? I think that announcement you're remembering was internal; IIRC, the internal instance was initially going to be retired, lots of people complained, then Miro announced it was back because someone was going to maintain it. Wherever that's happening, though, it doesn't appear to be in that GitHub repo, which since July 2023 has only had one small change in April 2024 and one small change in October 2025. The original announcement says (I think it's safe to post this small snippet publicly): You would normally use it to: - see which required tests need attention - check the results of unsatisfied tests - wave a failed test For Fedora, all those functions are fulfilled by Bodhi, so I'm not sure the dashboard would be terribly useful.

adamwill referenced this issue from apps/ci-resultsdb-listener

2026-06-11 15:39:15 +00:00

Add support for fedora-update type messages #29

adamwill referenced this issue from quality/planning

2026-06-11 16:32:33 +00:00

Make Fedora CI report rmdepcheck results directly and by update not build #67

adamwill added a new dependency

2026-06-11 16:32:50 +00:00

quality/planning#67 - Make Fedora CI report rmdepcheck results directly and by update not build

adamwill referenced this issue from quality/fedora_openqa

2026-06-18 09:36:45 +00:00

ci-resultsdb-listener and openqa results #90

adamwill commented

2026-06-23 08:04:40 +00:00

Author

Owner

So I believe we've tentatively decided to go ahead with this plan, right?

In #561 I intend to try converting the rmdepcheck pipeline to direct reporting as a sort of trial run / PoC.

So I believe we've tentatively decided to go ahead with this plan, right? In #561 I intend to try converting the rmdepcheck pipeline to direct reporting as a sort of trial run / PoC.

lecris commented

2026-06-23 08:06:23 +00:00

Owner

Yeah let's try it out

lecris removed a dependency

2026-06-23 08:06:35 +00:00

#561 rmdepcheck: publish messages (and hence report results) by update

lecris added a new dependency

2026-06-23 08:06:41 +00:00

#561 rmdepcheck: publish messages (and hence report results) by update

lecris removed the

Status/Discuss

label

2026-06-23 08:07:28 +00:00

mvadkert commented

2026-06-23 11:00:36 +00:00

Owner

I am a bit confused here, I thought the bodhi results are displayed from greenwave which needs the results to be in resultsdb and that in resultsdb the results get from the ci messages ...

mvadkert commented

2026-06-23 11:03:33 +00:00

Owner

ah, right, if we let the jenkins pipelines submit directly to resultsdb we should be fine dropping these.

adamwill commented

2026-06-23 11:34:54 +00:00

Author

Owner

yes, the idea is to drop out the "send a message so the message-consuming-reporter can report to resultsdb which also publishes a message" bit and just report to resultsdb directly.

mvadkert commented

2026-06-23 15:54:42 +00:00

Owner

Agreed, makes sense to me. This was actually also the plan for RHEL, but it burned on too many CI systems, what is not an issue here (we only have one). So +1 from me on the plan.

Rows
Columns

Stop publishing .ci. messages? #562