fedora-ci / messages

#129 brew-build.test.* results are imported with hardcoded scenario when scenario is not set
Closed by pholica. Opened by pholica.

Closed
Reopen Issue

Brew build.test.* messages have optional field test.scenario.

Greenwave seems to distinguish between results with specific scenarios and without any scenario meaning that if there's a result provided with scenario set and Greenwave doesn't expect scenario in a rule, such result is ignored for the rule. So far, this sounds like correct behaviour for me.

The current imported implementation however set's the result scenario as string "not available" instead of not setting it at all. This causes issues in Greenwave rules which don't use scenarios.

Please don't set scenario field in brew-build.test.* results if it's not set in the message.

Do you observe this behavior in Fedora or downstream? AFAIK, the services which ingest data into resultsdb are different in Fedora/downstream.

Since you're explicitly mentioning "brew-build", I am guessing we are talking RHEL CI here (?)

I'm hitting the issue in the downstream. There are no koji-build mappings defined for the importer in: mapping directory.

I see, that might be a problem indeed. Unless greenwave understands that "not available" actually means no scenario.

cc @lholecek

If scenario is not specified in required rules, Greenwave needs all results with any scenario to be passing.

See: https://gating-greenwave.readthedocs.io/en/latest/policies.html#passingtestcaserule

That said, I like the patch #130 because from Greenwave's perspective there is no need to set any special value for scenario.

Ok, I've just checked that with the #130 being merged (message version 1.1.10), this is now resolved.
Thank you for cooperation on this :)

Metadata Update from @pholica:
- Issue status updated to: Closed (was: Open)
Metadata
None
None
None
None
None
Related Pull Requests
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.