Although it's a bit of a tangent to this issue: rpmdeplint is agnostic to the arch where it runs, it works fine to test other arches on x86_64. There may be a problem with task-rpmdeplint in Taskotron which is preventing it from running correctly though, I am not sure.

As per @dcallagh's suggestion, re-filed at https://pagure.io/taskotron/task-rpmdeplint/issue/11

Anyway, judging by the conversation in that issue against task-rpmdeplint, it seems we are going to need to make some short-term adjustments in Greenwave until we can get rpmdeplint running in a better way.

I think this means we will have to make Greenwave aware of arches so that we can write per-arch policies....?

I think Greenwave should be made arch-aware. One reason is the available infrastructure, it's unlikely we will be ever able to cover all arches equally. Another reason is there is still the differentiation primary vs secondary, it's used for upcoming releases composes now (release blocking/non-blocking), but it should be extended to the stable releases (via updates). An unsuccessful test for an update on secondary arch probably shouldn't block the whole update going out.

The major issue I see here is that if greenwave doesn't know about arches, it doesn't know if there's something important missing (e.g. a x86_64 result). We'll have to decide on a convention how to indicate that a particular test result is per-arch or universal (so that we produce results in the same way you consume it, e.g. using the arch extra key), and greenwave will probably need to have different rules for different arches (for example: block until all mandatory arches are tested && block if any result is fail ==> mandatory arches must have results present, alternative arches don't have to, but if there's any failure for any arch, the maintainer needs to look at it and waive it or unpush it).

Note that there's been an attempt to standardize some results conventions using https://pagure.io/taskotron/resultsdb_conventions by @adamwill. We probably want a text description, though, not code.

FWIW, greenwave does already know about the scenario which may be a handy substitute for arches.

scenario is a handy way to distinguish different results in an automated fashion - take two results for the same testcase+item+type and compare their scenario, if it is the same, the latter supersedes the former, if they're different, they are two separate results. The value of scenario is undefined, though, and in control of the test author (it can be i386, or i386+uefi, or asdf). At least that's my memory of how this field should work. You should not try to parse it, and it will not help you with determining whether e.g. x86_64 result exists.

That's more or less correct, yes. We agreed the scenario should be taken as a whole and not parsed. The arch is one thing that almost always will be in the scenario, but trying to parse arches out of scenario is probably not the way to go about it.

I actually designed resultsdb_conventions with exactly the idea that we might want representations of the conventions in other forms; it kinda is intended to accommodate the possibility of generating text descriptions from the code, or introducing a sort of human-readable, structured-text intermediate format, or something along the lines of fedmsg_meta - anyway, the thought was in my mind. I didn't implement any of those yet. All results currently submitted via conventions (openQA and Autocloud results) should have an arch key. I believe some Taskotron results do, but not all? CI pipeline results do not have one. (For that matter, I think only conventions-submitted results have a scenario key, so far; I'm not sure we got even Taskotron emitting results with it, yet, and the pipeline definitely does not).

There's another wrinkle there, which is that there's a team working on a spec for CI (read 'automated test system') messaging (read 'fedmsg and RH's fedmsg equivalent') formats, and I'm part of it. It's also kind of in-scope for that project to define a standard format for resultsdb results too, which would be derived from or at least related in some way to the message format. Unfortunately I got slammed with Beta stuff so my work on that at least has come to a bit of a screeching halt, but we should definitely bear in mind that there is a will/intent to define some common format for this. All the work on this is behind RH firewalls at present, unfortunately (not a conspiracy, just that's where it started and no-one's done the work to convert it to some outside-the-firewall doc system yet), but I can point at least RH folks at what exists so far. Fedora openQA staging is emitting messages in approximately the current proposed format already, here are two examples.

Just checking - @sharkcz, is this still an issue for you now that bodhi has refactored how it displays results?

@sharkcz are you still hitting this issue given the recent changes in Bodhi to haw results are displayed?

I think the checks now work without blocking the non-x86 arches as they check only the whitelisted rpms (src, noarch, x86_64).

Great. Thanks!