649727 - L10n jobs on 2.0 and beta failing due to bad hg clones

Status: RESOLVED FIXED

(Release Engineering :: General, defect, P1)

Description

[Armen [:armenzg]]

I have clobbered the slave manually and put it back into the pull.

I will keep it open to check it is all back to normal.

Comment 1

[Dustin J. Mitchell [:dustin] (he/him)]

How did it burn them?

Comment 2

[Axel Hecht [:Pike]]

configure was borked, which usually dates back on a failed hg clone.

Comment 3

[Dustin J. Mitchell [:dustin] (he/him)]

ok, all yours, armen.

Comment 4

[Axel Hecht [:Pike]]

Today it's w32-ix-slave26.

Comment 5

[Dustin J. Mitchell [:dustin] (he/him)]

Let's address the underlying problem, then.

Comment 6

[Armen [:armenzg]]

linux64-ix-slave17 is now at fault.

Comment 7

[Dustin J. Mitchell [:dustin] (he/him)]

Armen, presumably this isn't the same bug, unless there's something correlating disk failure and l10n jobs.  Rather, I assume that since there are so many l10n jobs, they just happen to flush out slave failures more often than other jobs.

Can we close this bug, and file new bugs for each failed slave (as has already been done for the above slaves)?

Comment 8

[Armen [:armenzg]]

(In reply to comment #7)
> Armen, presumably this isn't the same bug, unless there's something correlating
> disk failure and l10n jobs.  Rather, I assume that since there are so many l10n
> jobs, they just happen to flush out slave failures more often than other jobs.
> 
> Can we close this bug, and file new bugs for each failed slave (as has already
> been done for the above slaves)?

That was the original purpose of this bug to deal with win32-slave13.

I have only dealt with linux-ix-slave17 (bug 648528).

Once I check the other two slaves I will file their own bugs and close this one.

Comment 9

[Armen [:armenzg]]

I don't have enough information for w32-ix-slave26.
I have clobbered nevertheless.

We will have to tackle new individual issues on new bugs.