This ticket had assigned some Differential requests:
D785

So I kinda have this working, but it's really ugly.

The problem is this: for this use case we need to take a Pungi 4 compose ID (which is what openQA knows) and find out if there's a Wikitcms event for that compose. This is not trivial because "what compose is this event for" is not easily discoverable for nightlies, with my current implementation where the nightly events are still named as before (they just have the date, no respin indicator). The way I made it work is:

• python-wikitcms converts the compose ID to a (release, milestone, compose) triple
• it gets a validation event instance for that triple, without specifying a compose location
• it checks if that validation event exists at all (by seeing if its download page contains any text)
• if the event exists, python-wikitcms then uses a really ugly hack to figure out what compose it's for (a nasty regex match on the download page to try and find a string that looks like a compose location)
• python-wikitcms then gets a fedfind release instance for that location and compares the fedfind release instance's compose ID with the one that was passed in; if it matches, you get the event, if it doesn't, you get a ValueError

which, I mean, ew. It works. But it's just horrible. And it's all made a bit uglier by the fact that this is just one of several awkward use cases I have to deal with - in order to create the validation events in the first place, for instance, we have to be able to instantiate an event from a compose ID without it already existing (which is why the above workflow has to explicitly check if the event exists at all; if it doesn't, it just returns the event, to make that use case work).

I think the least awful approach available to us is to put the respin numbers into the nightly event names, from the Pungi 4 switchover onwards. I was resisting that because it makes things more complicated purely inside python-wikitcms. But it would make negotiating the Pungi / Wikitcms border rather a lot easier, so I think it's a net win overall. I'm gonna give that a shot next, anyhow, and see how it works out.

I also think that putting respin numbers into event names would be better solution (because this sounds really ugly). What will it complicate in python-wikitcms?

well, just a few things spread around the place; the get_validation_event and get_validation_page helpers get more complicated because they have to know that before Magic Date X, nightlies are identified by date, after Magic Date X, nightlies need a respin number too...the code that gets you the right kind of wikitcms Page instance for any given wiki page gets more complicated...it's just a bunch of little things. but I'm probably going to do it that way.

Just changing priority to High from Unbreak now, since the task is assigned, and it bugs me in the phab overview

well jeez, this somehow turned into a four day fedfind/wikitcms rewrite, but it's finally working now (just in time for releng to start mirroring candidates, which means I get to change it all again next week). I haven't written the consumer yet, but result reporting is working except for https://fedorahosted.org/fedora-infrastructure/ticket/5171 . The consumer should be pretty trivial to do.

D785 addresses this.

This is done and merged and working.