action #23364
closedLeap 42.2 aggregates tests not firing
0%
Description
No new tests are fired for the Leap 42.2 aggregated tests:
https://openqa.opensuse.org/group_overview/26
New updates were released, and new updates appeared and disappeared in the aggregated repository.
http://download.opensuse.org/update/leap/42.2-test/
The 42.3 equivalent works fine.
Updated by AndreasStieger almost 7 years ago
bot sais:
DEBUG:openqa-maintenance.py:incident tests for request 516928 are done, but need to wait for test repo
DEBUG:openqa-maintenance.py:incident tests for request 516930 are done, but need to wait for test repo
The results match up with the scenario of the 42.2 aggregated jobs not being regularly scheduled, looking..
Updated by AndreasStieger almost 7 years ago
- Status changed from New to Resolved
A bot was stuck in distri=opensuse version=42.2 build=20170811-5
openqa_client jobs/466020/cancel post
works now, new test triggered and reviews processed
Updated by okurz almost 7 years ago
- Category set to Regressions/Crashes
- Status changed from Resolved to In Progress
- Assignee set to EDiGiacinto
@Ettore, the one job https://openqa.opensuse.org/tests/466020# was in state "assigned". The web ui did not even give any information when this job was scheduled. https://github.com/os-autoinst/openQA/blob/master/docs/GettingStarted.asciidoc#jobs does not describe anything about the state "assigned" which I assume you added. Could you please fix the docs? Also, I am not sure if this issue would be fixed by more recent changes by you or if there is still something missing which can reappear as a problem.
Updated by EDiGiacinto almost 7 years ago
There is no description, because the work on that it was still in progress, but due to more urgent problems #20378 had to be merged. The assigned state is a very recent change, as long as i'm finished with writing full unit tests for the scheduler, along with the changes needed to deal with that new state, will update the docs.
Now it's in cancelled state. But still i do not see how this is related to the issue. For now you have to restart the worker to get it back from the assigned state.
Updated by okurz almost 7 years ago
- Assignee set to EDiGiacinto
EDiGiacinto wrote:
Now it's in cancelled state. But still i do not see how this is related to the issue. For now you have to restart the worker to get it back from the assigned state.
Yes, it's in cancelled state because I forced it from assigned to cancelled using an API request. The webUI does not offer a cancel button, it does not state when it was created or which worker it is assigned to. So "restart the worker" is not so easy when one does not know which worker.
I assigned the ticket to you to make sure this is not forgotten. If you say all of the issues I mentioned are covered by #20378 go ahead and reopen it and close the current ticket as "Resolved". IMHO just unassigning this ticket is not helping because who else should then ever pick up that ticket?
Updated by EDiGiacinto almost 7 years ago
- Status changed from In Progress to Resolved
If it goes to assigned state, it will have a worker assigned - if doesn't, it means something wrong happened in the DB side.
The ticket is regarding a specific set of tests, not at the problem in general, this is why should be closed. When you feel something is wrong wrt scheduler, please add it to the tracker or will get lost anyway : #20378
Edit: this is also another form of #23320
Updated by okurz almost 7 years ago
- Copied to action #23378: [tools][sprint 201709.1] Enhancement and cleanup of "assigned" state added