Comment 2 for bug 1654761

So here's some general notes and some questions that I have gathered regarding the implementation of this. Please note that this is my first time working with the Britney2 or autopkgtest-cloud code, so I might be somewhat off on some specifics, so please do correct me if I'm inaccurate anywhere here.

It seems to me that the way this is implemented is that when Britney triggers a test initially, it logs that test in pending.json. It then on each run determines whether the packages in pending.json have results on autopkgtest.u.c (by checking the Swift results) and if it does, get the status from there. If it doesn't, then it keeps it marked as RUNNING. This is pretty black and white; it doesn't scan the *queue* at all to see if there's tests already there. It seems to do something similar for the packages requested manually.

Since the AMQP queue can already be sent to in the autopkgtest policy, what I can try to do is if something in the queue exactly matches a test marked as REGRESSION (in the case of it being triggered manually) or a test marked as RUNNING (in the case of Britney triggering the test), I can change the result to be QUEUED. Additionally, if a test is marked as RUNNING-ALWAYSFAIL, and it meets the conditions previously stated, I can mark it as QUEUED-ALWAYSFAIL.

One thing I am unclear on after doing that is how tests that are already running would be detected. In the case that Britney triggers the test, it's clear; that's what we have implemented already. But I'm not sure about the logic should a test be manually triggered and not in the queue but indeed running; both the previous state (very likely "REGRESSION") and QUEUED would be inaccurate. Is there a queue specifically for running tests that can be scanned? What might be the best way to do this?

Thanks, and I look forward to feedback (and corrections, if necessary) on this.