Do I understand it correctly that you propose to introduce a new generic type, let's say build, which could be used for all of the above-mentioned artifacts so that the topic would be the same but the details about the build type would be included in the message content? The set of test related messages could then look like this:

build.test.complete
build.test.error
build.test.queued
build.test.running

Note we will be discussing this topic on the first standardization consortium meeting ...

will add you @psss

@psss @mvadkert Sorry for a delay in response, I was out of work.

Yes, that could be a good starting point, but I would like to collect more requirements that others could have. Maybe more specific types for each build type would be an option as well.

But let's get back to it after standardization con. meeting.

@psss +- :) we call it for now "product-build" ...

This issue now covers basically two topics. One is product-build and the other is that we still need a low level definition for bits or element artifacts like archives, zips, etc.

This is based on: discussion under https://pagure.io/fedora-ci/messages/pull-request/59:

Those can be represented as:
a) the child artifacts, product-build type
b) the child artifacts, another type
c) in a separate property, maybe rather in the build property of an event (for example see product-build.build.complete.json)
There would be no messages sent for the bits, hence a) and especially b) seem to be not suitable.
@mvadkert WDYT please?

We encountered this use case yesterday also with cloudforms product. And seems we will be wanting to add an adhoc kind of artifact, that can be basically anything, with an ID and an URL, so it can be referenced and found. I believe this could be then also used for your "subartifacts" of your product build ....

I am opening a new issue for this basic representation of the artifact.

OK - I think we can close this one now.