QA (public) » openQA Project (public) » openQA Tests (public)

Motivation¶

Generally, having the RETRY=1 proved beneficial, however we're still not sure about certain cases, nor it's impact on o3, for this, we need to investigate a bit.

Hello Santi, you can refer to http://openqa.qam.suse.cz/tests/38647#dependencies for one typical virtualization MU test dependency tree. 
- If two or more child jobs fail, how will this RETRY=1 make the rerun look like? 
- One job tree from root to leaves jobs after merging unnecessary reruns? 
- Or multiple job trees which is unnecessary and less efficient? 
- If the result can be one tree, it will be good to go. 

Otherwise, better to be more careful.

Suggestions¶

• Mock a typical virtualization MU (Ping Alice from Virtualization if needed), and run it in a Devel jobgroup
• For the impact on openSUSE we would need to have that enabled, but we can ask Dimstar, Lubos and Marcus directly if having this feature enabled would help them with reviews/failing jobs (while we gather a bit more data to answer: "how many jobs have passed upon after the retry for the last 7, 30, 90 days?")

Caveats¶

While this potentially could hide sporadic issues, the benefit of having a test automatically restarted due to openQA mistyping outweighs the risk (for now)