On Sun, 2018-05-20 at 10:32 +0100, Peter Robinson wrote:
Additionally, in /mnt/koji/compose/ we have at least 108 each of:
Fedora-Cloud-26-* Fedora-Docker-26* Fedora-Cloud-27-* Fedora-Docker-27*
These should be moved into a container and cloud sub directory like all the other pungi runs, then the find -mtime +14 can be run on them at the end of each compose like the rest of them. I noticed this some time ago but never got around to filing a ticket/PR to fix it.
Guys, next time you're going to do something like this can you *please* give me a heads up?
Remember I maintain a tool whose entire job is to *know where composes are*, and it's wired into various QA processes; if you're going to move composes around, please let me know before doing it. I woke up today to a flood of traceback mails whose basic cause is that fedfind can't find these composes any more because they got moved without anyone telling me ahead of time.
Now I've got to send out an emergency release to fix it, and moving composes around has a whole knock-on effect because it messes up part of the test suite which uses real-life data (a log of 180 days' worth of 'compose status changed' messages); this is going to be doubly difficult to deal with because by moving finished composes you have *rendered the data in those messages incorrect*. E.g. https://apps.fedoraproject.org/datagrepper/id?id=2018-dccb5b21-9b15-4735-b50... claims the URL for the compose is http://kojipkgs.fedoraproject.org/compose/Fedora-Cloud-27-20180517.0/compose , but if you look there, you won't find it any more. So now I have to do some kind of ugly workaround for that.