Pretty much any time someone pushes to build/tools, ten or twenty jobs will pull while the push is happening, and the clone will die with a message like "abort: data/release/patcher-configs/mozRelease-thunderbird-branch-patcher2.cfg.i@4e3c9992c551: no match found!" Non-mozharness, that sets RETRY (and the failed clone gets removed) and another slave takes the job and succeeds (or fails, and the third try works). Mozharness, we get https://tbpl.mozilla.org/php/getParsedLog.php?id=17123243&tree=Cedar where the clone failed, we went ahead with the hg up -C, that failed, we did a pull which got nothing new, hg up -C failed, pull got nothing, up -C failed, pull got nothing, up -C failed, pull got nothing, up -C failed, pull, up -C, pull, up -C... I'm not positive, but I think that if you don't want to just set RETRY and bail, rm -rf build/tools and another clone would work (at least, given enough retries), but continuing to pull doesn't appear to be the solution.

I think it'll be easy to add a clobber to try > 1.

This definitely takes mozharness further down the production-oriented path and further away from the developer-friendly path. It seems like that's where things are going, however: more of a production-oriented solution that can be easier to replicate locally than buildbotcustom factories. I'll test this.

Comment on attachment 693080 [details] [diff] [review] clobber dest on retry My main concern here is if people want to use mozharness with anything resembling a local tree (local changes, local patch queue, etc.) then this will blow away their local changes. But as I stated above, it seems like mozharness' production-oriented side has taken over.

Comment on attachment 693080 [details] [diff] [review] clobber dest on retry http://hg.mozilla.org/build/mozharness/rev/a4518e40c78d