#81 Mandatory and optional messages
Closed by msrb. Opened by msrb.

I am wondering if it would make sense to make some messages optional. CI systems would only need to support mandatory messages to be compliant with the standard. This could make adoption of the standard easier.

For example "running" messages seem to be a good candidate for the optional flag. Potentially even "complete" and "error" messages could be optional.

WDYT?


@msrb running messages are optional. Complete and error should not be optional .... What is the reason which makes you think they could be optional?

When you say "running messages are optional", is this documented somewhere?

Complete and error should not be optional .... What is the reason which makes you think they could be optional?

That was just an idea. I think what's important is that CI systems publish test results in ResultsDB. And whether it happens via REST API or via messages and updater shouldn't be all that important at the end. Whoever's interested in test results could (and maybe should? as it is the source of truth) listen for notifications from ResultsDB.

When you say "running messages are optional", is this documented somewhere?

It is in the message schema

$ grep -R optional
component-version.test.running.yaml:    This is an optional message.
productmd-compose.test.queued.yaml:    This is an optional message.
product-build.build.queued.yaml:    This is an optional message.
component-version.test.queued.yaml:    This is an optional message.
pipeline.yaml:            An optional pipeline build number.
productmd-compose.test.running.yaml:    This is an optional message.
koji-build.test.running.yaml:    This is an optional message.
product-build.gate.running.yaml:    This is an optional message.
container-image.test.running.yaml:    This is an optional message.
product-build.test.queued.yaml:    This is an optional message.
component-version.yaml:            Task ID of the koji build on which the test was performed, optional.
component-version.yaml:            Build issuer of the artifact on which the test was performed, optional.
component-version.yaml:            Name-version-release of the artifact on which the test was performed, optional.
product-build.gate.queued.yaml:    This is an optional message.
brew-build.test.running.yaml:    This is an optional message.
product-build.test.running.yaml:    This is an optional message.
product-build.build.running.yaml:    This is an optional message.
brew-build.test.queued.yaml:    This is an optional message.
container-image.test.queued.yaml:    This is an optional message.
koji-build.test.queued.yaml:    This is an optional message.

It is in the message schema

Ah! I had "gate.running" message opened. That's why I didn't see it.

Ok, in that case this issue is not really valid.

Thanks ;)

That was just an idea. I think what's important is that CI systems publish test results in ResultsDB. And whether it happens via REST API or via messages and updater shouldn't be all that important at the end.

Yeah well, I would discourage to use directly the rest api really in our cases ....

Whoever's interested in test results could (and maybe should? as it is the source of truth) listen for notifications from ResultsDB.

TBH I consider the source of truth the messages, not resultsdb :) note the standard is more then just test results.

Metadata Update from @msrb:
- Issue status updated to: Closed (was: Open)

Metadata