#245: Add support for test re-scheduling --------------------+------------------------------------------------------- Reporter: kparal | Owner: Type: task | Status: new Priority: major | Milestone: 0.5.0 Component: core | Keywords: --------------------+------------------------------------------------------- After we start sending results to Bodhi/ResultDB there will immediately emerge a need for test re-scheduling. There may be different reasons for that:
1. Something went wrong in the test execution, we need to run it again. 2. The environment has changed and test needs to be executed once again. For example the upgradepath test for some update failed because of invalid package versions in higher Fedora releases. That problem has been corrected and we need now a new execution of the test.
The important thing is that the maintainer should be able to trigger the re-scheduling, not just us.
Find a way how to properly reschedule tests (we will probably utilize ResultDB for that) and add that functionality.
#245: Add support for test re-scheduling --------------------+------------------------------------------------------- Reporter: kparal | Owner: Type: task | Status: new Priority: major | Milestone: 0.5.0 Component: core | Resolution: Keywords: | --------------------+------------------------------------------------------- Comment (by jlaska):
Not sure if this addresses the request, but when I need to reschedule a test, I typically 'clone' the job using the autotest web or command interface. That uses the same control file and allows you to modify the control file and alter the client machine selection if desired.
#245: Add support for test re-scheduling --------------------+------------------------------------------------------- Reporter: kparal | Owner: Type: task | Status: new Priority: major | Milestone: 0.5.0 Component: core | Resolution: Keywords: | --------------------+------------------------------------------------------- Comment (by jlaska):
Replying to [ticket:245 kparal]:
The important thing is that the maintainer should be able to trigger the
re-scheduling, not just us.
Oh oops, I missed this critical part of your post. If I understand correctly, this is to capture the case when a maintainer builds updates out of order? Meaning, they don't start with rawhide and work back? So they start with F-14 (or older), which fails because an older package version is in rawhide.
One way to re-schedule is to use the existing scheduling method and submit a new update. That only applies if there are some bugs they are fixing and they are bumping the NVR. For the case of upgradepath, they likely won't rebuild a newer version just to resolve this test timing issue.
Assuming resultsdb was in place, the maintainer could of course WAIVE the test result with a comment indicating that the rawhide build is inprogress, and rescheduling wouldn't be required. Long-term, it'd be nice to have some link/button on bodhi (or resultsdb) that would submit a reschedule to autoqa/autotest.
#245: Add support for test re-scheduling --------------------+------------------------------------------------------- Reporter: kparal | Owner: Type: task | Status: new Priority: major | Milestone: Future tasks Component: core | Resolution: Keywords: | --------------------+------------------------------------------------------- Changes (by kparal):
* milestone: 0.5.0 => Future tasks
autoqa-devel@lists.fedorahosted.org
-
fedora-badges