So, as the fedora-update artifact got merged into ci-messages, the builds dict and the id are mandatory for all the messages. Both of this encapsulate information about the builds contained in the update at the time the test was run (on the basis that updates can be edited, so it's important for message consumers to know what was actually in the update as the test tested it).

Unfortunately right now we don't and can't include this info in the messages we publish from openQA, so the messages aren't technically complying with the spec.

Fixing this is...interesting...because at present the implementation is that we download the update packages during the test itself. This has two obvious implications:

1. If the test fails before that point, or during the download, we just don't have the information at all
2. We can't just capture the info on what's in the update in fedora_openqa code before the test runs and use that in the messages, as if the update is edited between the test being scheduled and the test downloading the packages, the info will be wrong

So, there are a few ways we can address this, and none of them is super clean, but I think the best and most robust would be just to change how we actually do the testing. The approach would be something like having the scheduler capture information about the builds in the update at the time of scheduling, and pass that info into the test as variables. We would then change the test code to always download those builds, rather than just using the Bodhi CLI to download whatever builds are in the update at the time the command runs - probably by using Koji CLI instead of Bodhi CLI (an alternative would be to have the scheduler actually set up a repo for the tests to use, but I don't think I like that). The messaging code could then also read the info out of the variables and include it in the messages.

I like this approach best because it ensures the info is always available for inclusion in messages even if the test fails early or otherwise somehow doesn't store info on what packages it used, and should ensure the info in the messages is always consistent with what the test actually tested. It does mean we have yet more "implementation detail" variables in the tests, but meh, that's a relatively small drawback.