712538 - Make leaktest steps on try as sane as the ones on non-try are

Status: RESOLVED FIXED

(Release Engineering :: General, defect)

Description

[Phil Ringnalda (:philor)]

In bug 620282, we switched leaktest away from the previous set of steps which pointlessly tried to create a profile, and to then use that profile, both times getting trippped up by the fact that the combination of leaktest.py and automation.py were going to run the step in a different freshly created profile each time, to just three steps: pass -register, run with no args for an alivetest, then run with -trace-malloc on platforms where we do trace-malloc.

However, probably because I didn't realize that try's steps were separate, we left try doing things the old way, which today tripped tbsaunde, since his push to try was green, but his push to m-c failed because without the dilly-dallying of the don't-actually-create-a-profile and don't-actually-use-the-profile steps, he was somehow winding up with the http server from the first run still going and stopping the second run from being able to start it up again.

We need to make try able to break him there, too, by taking out the whole hunk in http://hg.mozilla.org/build/buildbotcustom/annotate/4414dbcecb75/process/factory.py#l1870 :)

Comment 1

[Phil Ringnalda (:philor)]

Attachment: fix v.1

Remember: untested, incompetent, usually not actually able to successfully copy-paste, you want to run it in staging, you do not want to assume that this is the time I'll have finally managed to not screw a buildbot patch up.

Comment 2

[Lukas Blakk [:lsblakk] use ?needinfo]

Comment on attachment 583392 [details] [diff] [review]
fix v.1

Philor, thank you for this patch - I'm really not going to have time to run it through its paces any time in the near future (and it's already been around a while).  Can you ping in #build and find someone who's currently testing things in a local test env to give this a kick?

Comment 3

[Phil Ringnalda (:philor)]

Comment on attachment 583392 [details] [diff] [review]
fix v.1

In the intervening time, I've lost all my shyness about breaking things. It probably works, anyway.

Comment 4

[Chris Cooper [:coop] (he/him)]

Comment on attachment 583392 [details] [diff] [review]
fix v.1

Review of attachment 583392 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good to me. I'll fire it up it staging tonight and hopefully land it tomorrow.

Comment 5

[Chris Cooper [:coop] (he/him)]

(In reply to Chris Cooper [:coop] from comment #4)
> Looks good to me. I'll fire it up it staging tonight and hopefully land it
> tomorrow.

Still trying to get this tested in staging. Cloning try is proving to be a pain from the dev environment.

Comment 6

[Chris Cooper [:coop] (he/him)]

Comment on attachment 583392 [details] [diff] [review]
fix v.1

Try leak tests ran fine in staging once I pulled from a non-try repo.

https://hg.mozilla.org/build/buildbotcustom/rev/bdd5e90dc50f

Comment 7

[Armen [:armenzg]]

This change went live in a reconfiguration around 9AM.

Comment 8

[Phil Ringnalda (:philor)]

Horrifying though it was, I looked at a full debug log from try, and it did just what it should have done.