As suggested by @sdharane , we could write a little script to check that the packages we request to be included in composes actually make it in.
The 'check if package X is in the compose' part of this should be trivial, as fedfind already has code for that. A bit harder is 'parse the compose request and pull out a list of packages to check for', since the requests are technically unstructured text; we usually paste a request generated by blockerbugs, but in theory we don't have to and we do sometimes hand-edit it and add text to it, sometimes saying things like "not including XXX" which could be tricky to parse. There's also the question of knowing which comments from the request ticket associate with the latest compose.
My initial plan for this would, I guess, be to parse every comment on the ticket, pull out every line that looks exactly like how blockerbugs generates them (and ignore any other line), parse all package NVRs out of those lines, reduce to the latest listed NVR for each package, and query for those in the most recent candidate compose.
Instead of producing and parsing markdown text, it might be better to agree on a specific format with releng team (whatever is the most useful for them to paste into their build system/command line), and then include that snippet as a code block into the ticket, ideally with some identifying header. So e.g.
# blockerbugs compose request nvr1 nvr2
or
# blockerbugs compose request # bugzilla url 1 # bodhi url 1 nvr1 # bugzilla url 2 # bodhi url 2 nvr2 nvr3
Imo, we don't need to fiddle with format too much, we'd just look for https://bodhi.fpo.org/* (terminated with space) , fetch nvrs from bodhi through its api and leave just the highest ones that we'd then check the compose for.
No, we can't do that, because the requests are for the exact builds listed, not for "whatever is in this update at any given time", and updates can be (and have been) edited while this whole process is "in flight". When that happens it can be a problem to get the right thing pushed stable, but that's not relevant here, the point is that's a bear trap we have to be aware of :)
Login to comment on this ticket.