backoffLimit for the test job set to 0.

[gusmith]

Otherwise, thed efault value is 6, which means that the job restarts up to 6 time a pod if the previous one failed.

[hardbyte]

I guess we might see more failures by removing this retry mechanism... I'd have like to have a rational provided but I'm approving assuming you have one.

[gusmith]

Currently, when the python tests fail (e.g. a timeout), the pod returns an error, and the job restart another pod. Which creates a number of new deployments problems. In fact, the pod is mounting a volume which cannot be attached to multiple pods, and at the same time the job trying to publish the results is trying to access the same volume.
The problem was observed in the build https://dev.azure.com/data61/Anonlink/_build/results?buildId=553 (attempt 4 of the tests on kubernetes): the pod trying to publish the results cannot access the volume where the tests results are because another pod is trying to mount the same volume.

In all cases, I do not think it makes sense to re-run the same test if a failure occurs as we may want to see all the failing tests.