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

adamwill commented

2026-05-20 18:14:51 +00:00

Owner

Currently, when testing updates, the pipeline publishes messages by NVR. This means we get as many messages (and hence resultsdb results) as there are builds in the update; for a 500-package update we get 500 messages and 500 results. This looks a bit goofy on the Automated Tests tab:

and so on.

Since rmdepcheck is a test of the update, and it's not possible to definitively associate rmdepcheck failures with any specific package in the update, we should send messages and thus report results for the update as a whole, not for each individual NVR.

It looks like, in order to do this, we want to make the pipeline's sendMessage calls hit FedoraUpdateMessageBuilder not RpmBuildMessageBuilder. To achieve that, we have to fiddle with what the pipeline passes as artifactId and/or additionalArtifactIds.

Looking closely at the pipeline library code, it looks like this path expects something it calls a "composite artifact ID", which I think looks something like this:

(koji-build:foo-1.0-1.fc45,koji-build:bar-2.0-2.fc45)->fedora-update:FEDORA-2026-abcd

So we'd have to massage the pipeline into sending that?

Or I guess we could say that's kinda crazy, and we could rewire FedoraUpdateMessageBuilder to work more sensibly. To me it'd make sense if, for updates, we called:

sendMessage(type: '<type>', artifactId: params.BODHI_UPDATE_ID, additionalArtifactIds: params.ARTIFACT_IDS...)

i.e. the artifact ID is the advisory ID, the additional artifact IDs are the NVRs. Then the message builder could easily construct the message in the intended form:

    "artifact": {
      "alias": "FEDORA-2026-abcd",
      "builds": [
        {
          "nvr": "foo-1.0-1.fc45",
          "nvr": "bar-2.0-2.fc45"
        }
      ],
      ...

It feels to me like maybe the FedoraUpdateMessageBuilder design is very old and possibly predates the additionalArtifacts concept or something? Do we know if anything actually uses that path ATM?

After that, we'd have to look at the thing that converts CI messages to resultsdb results - ci-resultsdb-listener. It currently seems to make some assumptions that are only valid for RPM build type messages - just look at the main message body constructor:

        data = {
            "build_url": message.body["run"]["url"],
            "repo": message.body["artifact"]["component"],
            "nvr": message.body["artifact"]["nvr"],
            "item": message.body["artifact"]["nvr"],
            "scratch": message.body["artifact"]["scratch"],
            "username": message.body["artifact"]["issuer"],
            "koji_task_id": message.body["artifact"]["id"],
            "namespace": message.body["test"]["namespace"],
            "type": message.body["artifact"]["type"].replace("-", "_"),
            "test_type": message.body["test"]["type"],
            "category": message.body["test"]["category"],
        }

so I suspect it cannot currently report results for update type messages. So we'd also need to fix that.

Currently, when testing updates, the pipeline publishes messages by NVR. This means we get as many messages (and hence resultsdb results) as there are builds in the update; for a [500-package update](https://bodhi.fedoraproject.org/updates/FEDORA-2026-80fbb4aa1a) we get 500 messages and 500 results. This looks a bit goofy on the Automated Tests tab: ![image](/attachments/08b7da74-416f-460d-825d-8a356a65ad87) and so on. Since rmdepcheck is a test of the update, and it's not possible to definitively associate rmdepcheck failures with any specific package in the update, we should send messages and thus report results for the update as a whole, not for each individual NVR. It looks like, in order to do this, we want to make the pipeline's `sendMessage` calls hit [FedoraUpdateMessageBuilder](https://github.com/fedora-ci/jenkins-pipeline-library/blob/master/src/org/fedoraproject/jenkins/messages/FedoraUpdateMessageBuilder.groovy) not [RpmBuildMessageBuilder](https://github.com/fedora-ci/jenkins-pipeline-library/blob/master/src/org/fedoraproject/jenkins/messages/RpmBuildMessageBuilder.groovy). To achieve *that*, we have to fiddle with what the pipeline passes as `artifactId` and/or `additionalArtifactIds`. Looking closely at the pipeline library code, it looks like this path expects something it calls a "composite artifact ID", which I think looks something like this: ``` (koji-build:foo-1.0-1.fc45,koji-build:bar-2.0-2.fc45)->fedora-update:FEDORA-2026-abcd ``` So we'd have to massage the pipeline into sending that? Or I guess we could say that's kinda crazy, and we could rewire FedoraUpdateMessageBuilder to work more sensibly. To me it'd make sense if, for updates, we called: ``` sendMessage(type: '<type>', artifactId: params.BODHI_UPDATE_ID, additionalArtifactIds: params.ARTIFACT_IDS...) ``` i.e. the artifact ID is the advisory ID, the additional artifact IDs are the NVRs. Then the message builder could easily construct the message in the intended form: ``` "artifact": { "alias": "FEDORA-2026-abcd", "builds": [ { "nvr": "foo-1.0-1.fc45", "nvr": "bar-2.0-2.fc45" } ], ... ``` It feels to me like maybe the FedoraUpdateMessageBuilder design is very old and possibly predates the `additionalArtifacts` concept or something? Do we know if anything actually *uses* that path ATM? After that, we'd have to look at the thing that converts CI messages to resultsdb results - [ci-resultsdb-listener](https://forge.fedoraproject.org/apps/ci-resultsdb-listener). It currently seems to make some assumptions that are only valid for RPM build type messages - just look at the main message body constructor: ``` data = { "build_url": message.body["run"]["url"], "repo": message.body["artifact"]["component"], "nvr": message.body["artifact"]["nvr"], "item": message.body["artifact"]["nvr"], "scratch": message.body["artifact"]["scratch"], "username": message.body["artifact"]["issuer"], "koji_task_id": message.body["artifact"]["id"], "namespace": message.body["test"]["namespace"], "type": message.body["artifact"]["type"].replace("-", "_"), "test_type": message.body["test"]["type"], "category": message.body["test"]["category"], } ``` so I suspect it cannot currently report results for update type messages. So we'd also need to fix that.

image.png

168 KiB

lecris commented

2026-05-20 18:30:17 +00:00

Owner

Quick note, if you have a python-based approach or ideas for one, that would be preferred as we can migrate it to packit. I can figure out the missing bits of getting that into jenkins and hooking into the pipeline.

That would also bring us closer to the other ticket on exposing specific subtests also.

Quick note, if you have a python-based approach or ideas for one, that would be preferred as we can migrate it to packit. I can figure out the missing bits of getting that into jenkins and hooking into the pipeline. That would also bring us closer to the other ticket on exposing specific subtests also.

adamwill commented

2026-05-20 22:15:00 +00:00

Author

Owner

Approach to which bit? Publishing messages? Like, rewrite the sendMessage stuff as a standalone Python script or something? I mean, sure, we can do that, but it's rather beyond the scope of this ticket I think?

I don't have one handy, because we send the openQA messages out of openQA itself, so it's done in perl, as a custom openQA plugin that extends the upstream AMQP plugin.

Approach to which bit? Publishing messages? Like, rewrite the `sendMessage` stuff as a standalone Python script or something? I mean, sure, we can do that, but it's rather beyond the scope of this ticket I think? I don't have one handy, because we send the openQA messages out of openQA itself, so it's done in perl, as a [custom openQA plugin](https://src.fedoraproject.org/rpms/openqa/blob/rawhide/f/FedoraMessaging.pm) that extends the upstream AMQP plugin.

lecris commented

2026-05-21 08:13:35 +00:00

Owner

Approach to which bit? Publishing messages? Like, rewrite the sendMessage stuff as a standalone Python script or something?

Yeah, but

I don't have one handy

Oh well, let's see if hacking in the java thing is not a nightmare. Last time I looked at it, my tab did not remain open for long, but let's see if enough tea and this breakdown will help with that. What is the message schema expected on resultdb side?

artifactId: params.BODHI_UPDATE_ID, additionalArtifactIds: params.ARTIFACT_IDS

When I checked it, it just concatenated those two and the current logic is to loop over additionalArtifactIds. Maybe better would be to add a separate logic for bodhiUpdate that overrides it.

we get 500 messages and 500 results. This looks a bit goofy on the Automated Tests tab

Well, when we make enable rpminspect on it, it would be just as spammy 😅, but at least there it should have different results shown.

> Approach to which bit? Publishing messages? Like, rewrite the sendMessage stuff as a standalone Python script or something? Yeah, but > I don't have one handy Oh well, let's see if hacking in the java thing is not a nightmare. Last time I looked at it, my tab did not remain open for long, but let's see if enough tea and this breakdown will help with that. What is the message schema expected on `resultdb` side? > artifactId: params.BODHI_UPDATE_ID, additionalArtifactIds: params.ARTIFACT_IDS When I checked it, it just concatenated those two and the current logic is to loop over `additionalArtifactIds`. Maybe better would be to add a separate logic for `bodhiUpdate` that overrides it. > we get 500 messages and 500 results. This looks a bit goofy on the Automated Tests tab Well, when we make enable rpminspect on it, it would be just as spammy 😅, but at least there it should have different results shown.

adamwill commented

2026-05-21 15:34:12 +00:00

Author

Owner

Honestly I think I can work on this, I mostly filed the ticket as a notice of intent / research and to flag up the question I asked: do we work with the format FedoraUpdateMessageBuilder currently expects, or change it to expect a less-weird format?

I'd prefer to change it, but if there's something that actually uses the current format, that would be an argument for keeping it the way it is. I suspect there isn't, though. Today I intended to poke about a bit and try to find out.

What is the message schema expected on resultdb side?

resultsdb inherently has almost no expectations; iirc the only actual rules are you have to provide some kind of "test name" and you have to provide an outcome that's within the set the resultsdb instance knows of. Outside of that everything is in the air.

I made up some expectations, though, in the form of a Python project called resultsdb_conventions which encodes some opinions about what results for various types of artifact should look like. openQA uses that project and so its results are in the format it expects/enforces. It seems sensible to me that ci-resultsdb-listener should follow the same format, even if we don't make it literally use resultsdb_conventions. The format isn't particularly complex for update results. It doesn't currently include / expect the list of NVRs tested, but if we found it useful we could add that, I guess.

When I checked it, it just concatenated those two and the current logic is to loop over additionalArtifactIds. Maybe better would be to add a separate logic for bodhiUpdate that overrides it.

If you're looking at sendMessage, yeah, that's correct. It currently is hardwired to (attempt to) publish a message for every single artifact ID, including all the ones in additionalArtifactIds. But of course we could change that fairly easily. Or there's other ways to slice the cat - if we decide it's OK to rewrite the update path, I will just figure out whatever looks best to me as I go along.

Honestly I think I can work on this, I mostly filed the ticket as a notice of intent / research and to flag up the question I asked: do we work with the format `FedoraUpdateMessageBuilder` currently expects, or change it to expect a less-weird format? I'd prefer to change it, but if there's something that actually uses the current format, that would be an argument for keeping it the way it is. I *suspect* there isn't, though. Today I intended to poke about a bit and try to find out. > What is the message schema expected on resultdb side? resultsdb inherently has almost no expectations; iirc the only actual rules are you have to provide *some* kind of "test name" and you have to provide an outcome that's within the set the resultsdb instance knows of. Outside of that everything is in the air. *I* made up some expectations, though, in the form of a [Python project called resultsdb_conventions](https://forge.fedoraproject.org/quality/resultsdb_conventions) which encodes some opinions about what results for various types of artifact should look like. openQA uses that project and so its results are in the format it expects/enforces. It seems sensible to me that `ci-resultsdb-listener` should follow the same format, even if we don't make it literally use resultsdb_conventions. The format isn't particularly complex for update results. It doesn't currently include / expect the list of NVRs tested, but if we found it useful we could add that, I guess. > When I checked it, it just concatenated those two and the current logic is to loop over additionalArtifactIds. Maybe better would be to add a separate logic for bodhiUpdate that overrides it. If you're looking at `sendMessage`, yeah, that's correct. It currently is hardwired to (attempt to) publish a message for *every single* artifact ID, including all the ones in `additionalArtifactIds`. But of course we could change that fairly easily. Or there's other ways to slice the cat - if we decide it's OK to rewrite the update path, I will just figure out whatever looks best to me as I go along.

lecris commented

2026-05-21 15:42:54 +00:00

Owner

@adamwill wrote in #561 (comment):

I'd prefer to change it, but if there's something that actually uses the current format, that would be an argument for keeping it the way it is. I suspect there isn't, though.

There is an OSCI elephant lurking behind you. Yeah, they are pulling that one 🤷. As long as it's an additive interface it should be fine though, and they are locking specific git commits anyway.

What is the message schema expected on resultdb side?

resultsdb inherently has almost no expectations; iirc the only actual rules are you have to provide some kind of "test name" and you have to provide an outcome that's within the set the resultsdb instance knows of. Outside of that everything is in the air.

Hmm, but there must be some format that is then consumed by bodhi to display it right? Main reason for the schema question is that I find it easier to visualize an example payload from it (in retrospect I might have spent way too much time writing json schemas 😅).

@adamwill wrote in https://forge.fedoraproject.org/ci/tickets/issues/561#issuecomment-742723: > I'd prefer to change it, but if there's something that actually uses the current format, that would be an argument for keeping it the way it is. I _suspect_ there isn't, though. There is an OSCI elephant lurking behind you. Yeah, they are pulling that one 🤷. As long as it's an additive interface it should be fine though, and they are locking specific git commits anyway. > > What is the message schema expected on resultdb side? > > resultsdb inherently has almost no expectations; iirc the only actual rules are you have to provide _some_ kind of "test name" and you have to provide an outcome that's within the set the resultsdb instance knows of. Outside of that everything is in the air. Hmm, but there must be some format that is then consumed by bodhi to display it right? Main reason for the schema question is that I find it easier to visualize an example payload from it (in retrospect I might have spent way too much time writing json schemas 😅).

adamwill commented

2026-05-21 16:50:07 +00:00

Author

Owner

Hmm, but there must be some format that is then consumed by bodhi to display it right?

Yeah, indeed. Bodhi's requirement is simply that the result's type is "bodhi_update" and its item is the advisory ID: github.com/fedora-infra/bodhi@7e598c7d9b/bodhi-server/bodhi/server/models.py (L2327)

> Hmm, but there must be some format that is then consumed by bodhi to display it right? Yeah, indeed. Bodhi's requirement is simply that the result's `type` is `"bodhi_update"` and its `item` is the advisory ID: https://github.com/fedora-infra/bodhi/blob/7e598c7d9b5b80b16fac537d92e01d022513f730/bodhi-server/bodhi/server/models.py#L2327

adamwill commented

2026-05-21 16:51:01 +00:00

Author

Owner

The format we use for openQA update results (produced by resultsdb_conventions) is not complicated, here's a sample message. The only bits of that which actually matter for Bodhi are the outcome, the testcase, the type, the item, and the scenario. Oh, and maybe the logs link?

The format we use for openQA update results (produced by resultsdb_conventions) is not complicated, [here's a sample message](https://resultsdb.fedoraproject.org/results/48287970). The only bits of that which actually matter for Bodhi are the outcome, the testcase, the type, the item, and the scenario. Oh, and maybe the logs link?

adamwill commented

2026-05-21 23:01:29 +00:00

Author

Owner

There is an OSCI elephant lurking behind you. Yeah, they are pulling that one 🤷

Are you sure? I did a search for "fedora-update" in the fedora-ci org on GitHub and didn't turn up anything. I also looked through recent ci.* messages and didn't spot any update ones that didn't come from openQA. Is there definitely something using FedoraUpdateMessageBuilder ?

> There is an OSCI elephant lurking behind you. Yeah, they are pulling that one 🤷 Are you sure? I did a search for "fedora-update" in the fedora-ci org on GitHub and didn't turn up anything. I also looked through recent ci.* messages and didn't spot any update ones that didn't come from openQA. Is there definitely something using FedoraUpdateMessageBuilder ?

lecris commented

2026-05-22 06:06:53 +00:00

Owner

@adamwill wrote in #561 (comment):

Is there definitely something using FedoraUpdateMessageBuilder ?

Not FedoraUpdateMessageBuilder per se, but of jenkins-pipeline-library as a whole: https://github.com/fedora-ci/jenkins-pipeline-library/pull/100#issuecomment-4224117840

@adamwill wrote in https://forge.fedoraproject.org/ci/tickets/issues/561#issuecomment-742917: > Is there definitely something using FedoraUpdateMessageBuilder ? Not `FedoraUpdateMessageBuilder` per se, but of `jenkins-pipeline-library` as a whole: https://github.com/fedora-ci/jenkins-pipeline-library/pull/100#issuecomment-4224117840

adamwill commented

2026-05-22 06:17:11 +00:00

Author

Owner

oh sure, I was assuming plenty of things use the library. But if nothing is actually using FUMB ATM, I can rewrite that specific path to behave the way that makes sense to me, that's the point.

👍 1

lecris commented

2026-05-22 06:39:17 +00:00

Owner

Yeah, I expect it should be fine modulo someone used it through some inheritance for some reason.

@adamwill wrote in #561 (comment):

oh sure, I was assuming plenty of things use the library

Wish they didn't with the current state of maintenance 🥲. Well hopefully we can just pass the problem down to osci when we can finally drop Jenkins

Yeah, I expect it should be fine modulo someone used it through some inheritance for some reason. @adamwill wrote in https://forge.fedoraproject.org/ci/tickets/issues/561#issuecomment-742941: > oh sure, I was assuming plenty of things use the library Wish they didn't with the current state of maintenance 🥲. Well hopefully we can just pass the problem down to osci when we can finally drop Jenkins

msrb commented

2026-05-26 12:11:54 +00:00

Owner

I think I can provide some context here 😉

Looking closely at the pipeline library code, it looks like this path expects something it calls a "composite artifact ID", which I think looks something like this:

(koji-build:foo-1.0-1.fc45,koji-build:bar-2.0-2.fc45)->fedora-update:FEDORA-2026-abcd

So we'd have to massage the pipeline into sending that?

It's structured like this:

*-trigger pipelines understand the events that should be triggering CI -- this can be a new koji/module build, Pagure MR opened/updated/commented on, Bodhi update, ... triggers translate those events into pipeline params
*-pipeline is what encapsulates the actual test. Tests expect certain type of artifact(s) on input, e.g. Koji build, Red Hat module. That's why -trigger doesn't pass for example Bodhi update id to the test, because the test doesn't know what to do with it.
In *-pipeline, ARTIFACT_ID param is what will be tested and the results will be reported for this artifact, and ADDITIONAL_ARTIFACT_IDS are just additional artifacts that should be present in the environment during testing

Sometimes, the trigger is a scratch build from Koji, so the ARTIFACT_ID is koji-build:1234, but this scratch build was created in a Pagure pull request and the result must be reported for the merge request (which didn't trigger the pipeline), otherwise Pagure listener won't catch the result. However, the actual test expects the Koji build on the input, because it doesn't know what to do with Pagure merge requests... And the solution for this problem is the weird (koji-build:1234)->fedora-dist-git:ff0abc syntax. It basically means "test this artifact, but report results for that other artifact". All you need to do is to pass this ARTIFACT_ID param from the trigger pipeline to the test pipeline. And the library should just correctly handle it.

If it's written this way, the same test pipeline transparently handles many combinations of triggers and outputs, without various "if this artifact, but pull request in Fedora, then..." statements all over the place. And that's how it was initially running for Pagure pull requests, Koji builds, Bodhi updates, and tests/. Plus internally for Brew builds, modules, and composes.

However... most of those use cases don't exist anymore. Fedora replaced Fedora CI with Packit for pull requests, and if your only input is Bodhi update and you know that you will be only reporting results for Bodhi updates (Fedora-specific, not reusable downstream), then you don't need this. And I'd even consider bypassing messaging completely and just storing the results in ResultsDB directly...

After that, we'd have to look at the thing that converts CI messages to resultsdb results - ci-resultsdb-listener. It currently seems to make some assumptions that are only valid for RPM build type messages

Yep, that was the case back in 2020 as well: https://pagure.io/fedora-ci/general/issue/145

Wish they didn't with the current state of maintenance 🥲. Well hopefully we can just pass the problem down to osci when we can finally drop Jenkins

Nah... it's been working just fine for half a decade or more 😉 There wasn't really any noteworthy development around Greenwave/ResultsDB/messaging all those years...

I think I can provide some context here 😉 > Looking closely at the pipeline library code, it looks like this path expects something it calls a "composite artifact ID", which I think looks something like this: > > (koji-build:foo-1.0-1.fc45,koji-build:bar-2.0-2.fc45)->fedora-update:FEDORA-2026-abcd > > So we'd have to massage the pipeline into sending that? It's structured like this: * `*-trigger` pipelines understand the events that should be triggering CI -- this can be a new koji/module build, Pagure MR opened/updated/commented on, Bodhi update, ... triggers translate those events into pipeline params * `*-pipeline` is what encapsulates the actual test. Tests expect certain type of artifact(s) on input, e.g. Koji build, Red Hat module. That's why -trigger doesn't pass for example Bodhi update id to the test, because the test doesn't know what to do with it. * In `*-pipeline`, `ARTIFACT_ID` param is what will be tested and the results will be reported for this artifact, and `ADDITIONAL_ARTIFACT_IDS` are just additional artifacts that should be present in the environment during testing Sometimes, the trigger is a scratch build from Koji, so the `ARTIFACT_ID` is `koji-build:1234`, but this scratch build was created in a Pagure pull request and the result must be reported for the merge request (which didn't trigger the pipeline), otherwise Pagure listener won't catch the result. However, the actual test expects the Koji build on the input, because it doesn't know what to do with Pagure merge requests... And the solution for this problem is the weird `(koji-build:1234)->fedora-dist-git:ff0abc` syntax. It basically means "test this artifact, but report results for that other artifact". All you need to do is to pass this `ARTIFACT_ID` param from the trigger pipeline to the test pipeline. And the library should just correctly handle it. If it's written this way, the same test pipeline transparently handles many combinations of triggers and outputs, without various "if this artifact, but pull request in Fedora, then..." statements all over the place. And that's how it was initially running for Pagure pull requests, Koji builds, Bodhi updates, and tests/. Plus internally for Brew builds, modules, and composes. However... most of those use cases don't exist anymore. Fedora replaced Fedora CI with Packit for pull requests, and if your only input is Bodhi update and you know that you will be only reporting results for Bodhi updates (Fedora-specific, not reusable downstream), then you don't need this. And I'd even consider bypassing messaging completely and just storing the results in ResultsDB directly... > After that, we'd have to look at the thing that converts CI messages to resultsdb results - ci-resultsdb-listener. It currently seems to make some assumptions that are only valid for RPM build type messages Yep, that was the case back in 2020 as well: https://pagure.io/fedora-ci/general/issue/145 > Wish they didn't with the current state of maintenance 🥲. Well hopefully we can just pass the problem down to osci when we can finally drop Jenkins Nah... it's been working just fine for half a decade or more 😉 There wasn't really any noteworthy development around Greenwave/ResultsDB/messaging all those years...

lecris commented

2026-05-26 12:20:22 +00:00

Owner

@msrb wrote in #561 (comment):

And I'd even consider bypassing messaging completely and just storing the results in ResultsDB directly...

👍for me if there is an easy way to do so.

@msrb wrote in https://forge.fedoraproject.org/ci/tickets/issues/561#issuecomment-760092: > And I'd even consider bypassing messaging completely and just storing the results in ResultsDB directly... 👍for me if there is an easy way to do so.

adamwill commented

2026-05-26 14:57:02 +00:00

Author

Owner

*-pipeline is what encapsulates the actual test. Tests expect certain type of artifact(s) on input, e.g. Koji build, Red Hat module. That's why -trigger doesn't pass for example Bodhi update id to the test, because the test doesn't know what to do with it.

Well, this has shifted somewhat over time, I guess. Also, it's possible for triggers to pass more than one thing to the pipeline, obviously. In this case, the trigger passes both the update ID and the NVRs to the pipeline. So we have both pieces of information to work with, at least on this path, and can do something like "if we have an update ID, use reporting path X; if we don't, use reporting path Y".

In *-pipeline, ARTIFACT_ID param is what will be tested and the results will be reported for this artifact, and ADDITIONAL_ARTIFACT_IDS are just additional artifacts that should be present in the environment during testing

This also appears to have shifted, because we publish separate messages for everything in ADDITIONAL_ARTIFACT_IDS at present. edit: in fact, you wrote it that way. edit: well, I suppose this depends on what each pipeline passes in as artifactId and/or additionalArtifactIds; the rmdepcheck one currently does not pass an artifactId, and passes ARTIFACT_IDS as additionalArtifactIds, so we report for each NVR.

And I'd even consider bypassing messaging completely and just storing the results in ResultsDB directly...

This idea keeps coming up, but I don't totally get it. We still ought to publish messages, because messages are useful. Someone might be listening for them. We can replace the message -> result thingy with an independent result publisher, sure, but is it actually worth the effort? The message -> result thingy is already built and works, so isn't it actually easier to just keep using it? If we were starting from a blank page I'd probably write separate message publishing / result reporting code, but given we have something that works...

> *-pipeline is what encapsulates the actual test. Tests expect certain type of artifact(s) on input, e.g. Koji build, Red Hat module. That's why -trigger doesn't pass for example Bodhi update id to the test, because the test doesn't know what to do with it. Well, this has shifted somewhat over time, I guess. Also, it's possible for triggers to pass *more than one thing* to the pipeline, obviously. In this case, the trigger passes [both the update ID and the NVRs](https://github.com/fedora-ci/rmdepcheck-trigger/blob/8143075e42ca0e184452e12253cb66f35e87eae7/Jenkinsfile#L58-L59) to the pipeline. So we have both pieces of information to work with, at least on *this* path, and can do something like "if we have an update ID, use reporting path X; if we don't, use reporting path Y". > In *-pipeline, ARTIFACT_ID param is what will be tested and the results will be reported for this artifact, and ADDITIONAL_ARTIFACT_IDS are just additional artifacts that should be present in the environment during testing This also appears to have shifted, because we [publish separate messages for everything in ADDITIONAL_ARTIFACT_IDS](https://github.com/fedora-ci/jenkins-pipeline-library/blob/09d244f6156b9ad440b3394e4c9b126690a5aee8/vars/sendMessage.groovy#L40-L44) at present. edit: in fact, [you wrote it that way](https://github.com/fedora-ci/jenkins-pipeline-library/commit/86944b1bd30f06989f3bc1b75a9c4f63d0bb4923). edit: well, I suppose this depends on what each pipeline passes in as `artifactId` and/or `additionalArtifactIds`; the rmdepcheck one currently does not pass an `artifactId`, and passes `ARTIFACT_IDS` as `additionalArtifactIds`, so we report for each NVR. > And I'd even consider bypassing messaging completely and just storing the results in ResultsDB directly... This idea keeps coming up, but I don't totally get it. We still ought to publish messages, because messages are useful. Someone might be listening for them. We can replace the message -> result thingy with an independent result publisher, sure, but is it actually worth the effort? The message -> result thingy is already built and works, so isn't it actually easier to just keep using it? If we were starting from a blank page I'd probably write separate message publishing / result reporting code, but given we have something that works...

adamwill commented

2026-05-26 15:02:02 +00:00

Author

Owner

I suppose the argument is "resultsdb publishes messages when you create a result anyway, so the CI messages are dupes"? I guess that's arguable. But we'd at least want a transition period for anyone using the current messages, I suppose...

lecris commented

2026-05-26 15:04:10 +00:00

Owner

@adamwill wrote in #561 (comment):

And I'd even consider bypassing messaging completely and just storing the results in ResultsDB directly...

This idea keeps coming up, but I don't totally get it.

Oh I thought that the state was that sendMessage is not using fedora_messaging to send to ResultsDB. If it does currently use, then I am also 👎 to changing it to send directly. Don't want to have to now deal with making sure that the connection to ResultsDB is healthy, do retries and all that jazz.

@adamwill wrote in https://forge.fedoraproject.org/ci/tickets/issues/561#issuecomment-760183: > > And I'd even consider bypassing messaging completely and just storing the results in ResultsDB directly... > > This idea keeps coming up, but I don't totally get it. Oh I thought that the state was that `sendMessage` is not using fedora_messaging to send to ResultsDB. If it does currently use, then I am also :-1: to changing it to send directly. Don't want to have to now deal with making sure that the connection to ResultsDB is healthy, do retries and all that jazz.

adamwill commented

2026-05-26 16:23:11 +00:00

Author

Owner

I mean, yeah, AIUI this is how it works at present: the Jenkins pipelines call sendMessage to publish messages, and then an instance of ci-resultsdb-listener that runs in infra consumes the message and turns it into a resultsdb report.

IMBW, but that's how I've always understood it to be working.

I mean, yeah, AIUI this is how it works at present: the Jenkins pipelines call `sendMessage` to publish messages, and then an instance of [ci-resultsdb-listener](https://forge.fedoraproject.org/apps/ci-resultsdb-listener) that [runs in infra](https://forge.fedoraproject.org/infra/ansible/src/branch/main/playbooks/openshift-apps/resultsdb-ci-listener.yml) consumes the message and turns it into a resultsdb report. IMBW, but that's how I've always understood it to be working.

adamwill referenced this issue from quality/planning

2026-06-02 06:32:25 +00:00

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

adamwill commented

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

Author

Owner

I've sent a ci-resultsdb-listener PR that should allow for this (it should handle publishing a result if we start sending out messages by update rather than by build). But we might decide to do #562 instead, I guess? Let's talk it over at Flock.

I've sent a [ci-resultsdb-listener PR](https://forge.fedoraproject.org/apps/ci-resultsdb-listener/pulls/29) that should allow for this (it should handle publishing a result if we start sending out messages by update rather than by build). But we might decide to do https://forge.fedoraproject.org/ci/tickets/issues/562 instead, I guess? Let's talk it over at Flock.

adamwill was assigned by lecris

2026-06-10 10:01:13 +00:00

lecris added a new dependency

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

#562 Stop publishing .ci. messages?

lecris added the

Priority

High

area/jenkins

labels

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

lecris added this to the Board project

2026-06-10 10:13:58 +00:00

adamwill commented

2026-06-14 09:14:41 +00:00

Author

Owner

So we decided in principle to stop publishing .ci. messages and start reporting directly to resultsdb instead. I guess we can do this pipeline by pipeline; I could start with rmdepcheck (as it's the newest), and make it report by update at the same time...

adamwill referenced this issue

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

Stop publishing .ci. messages? #562

lecris removed a dependency

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

#562 Stop publishing .ci. messages?

lecris added a new dependency

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

#562 Stop publishing .ci. messages?

Rows
Columns

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