On Mon, 2018-03-26 at 17:06 +0000, Alessio Ciregia wrote: > On Mon, Mar 26, 2018, 5:21 PM pmkellly@xxxxxxxxxxxx <pmkellly@xxxxxxxxxxxx> > wrote: > > > Since the Gnome 3.28.0 test object for today was delivered as > > Fedora-Workstation-Live-x86_64-28-20180324.n.0.iso, I went ahead and did > > the rest of the testing. I was surprised when I could not report the > > results. relval said there was no test event for 20180324.n.0. Did I do > > something wrong > > > > Hello. Maybe someone else can explain better than me. > However, every day one or more composes are produced (let's call them > nightly builds) but you can report the results (directly on the wiki or via > relval) only on composes nominated for test (test event). Such nomination > is made automatically based on some heuristic rules. > In fact, if you visit the wiki page containing the results [1] you are not > supposed to find the latest compose, but instead the last nominated for > testing. > I think you can find more info here [2]. > > I hope I didn't wrote anything wrong. This is exactly correct, yes. A compose is attempted for Rawhide every single day (at least), and a compose is attempted for Branched every day that Branched exists. However, we do not create validation events for every single compose, so as not to overwhelm people with events (and the wiki with result pages). The rules for when an event is created are a bit complex, but it's more or less this: 1. We *never* automatically create events closer than 3 days together 2. If it's been 14 days since the last event, there will *definitely* be an event for the next successful compose 3. If a compose succeeds and it's been more than 3 days but less than 14 days since the last event, then a new event will be created if any of a hand-maintained list of 'important' packages changed since the last event. If not, there won't be an event. So yep, you can't expect there to be an event for every compose, at least the way we do things at present. Of course, you can still test things out on the composes that don't have corresponding events, and if you find a bug - file it! You just can't file 'pass' or 'fail' results into the wiki for them. We *could* potentially create an event for every compose, it's perfectly easy to do (it'd actually make the tooling a lot simpler), if folks think it would work better - do feel free to chip in with an opinion :). Also, if we ever get around to changing away from the wiki for release validation - that's https://pagure.io/fedora-qa/issue/152 - this would probably look different. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net _______________________________________________ test mailing list -- test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to test-leave@xxxxxxxxxxxxxxxxxxxxxxx
