As I understand it, when we're low on test-running-slaves, we sometimes coalesce consecutive builds' test-runs. (Doing only one run of tests for two pushes) When we do merge two push's tests like this, we kill tests for the "older of the two". Right now (according to nthomas and philor), "older of the two" is implemented as "the one whose build finished longest ago". However, we really want it to mean "the one whose changeset is an ancestor of the other." PUT ANOTHER WAY: When we coalesce two test runs, we should run tests for the most recent changeset -- not the most recently completed build.
This bug caused confusion on the mozilla-central trunk today. We had a push by bhearsum, followed by a push by khuey, but for whatever reason, khuey's build finished a minute before bhearsum's. The two builds' tests were coalesced, and when they were, khuey's test-runs were dropped, even though he had the more recent changeset. This means khuey didn't get any test results queued up for his changeset. (Of course, he'll end up getting results, from the cycle of whoever pushed after him -- it was just confusing to try to figure out why he didn't have his own test cycles.)
OS: Linux → All
Hardware: x86_64 → All
Not sure what needs to change here...something in the treeStableTimer perhaps?
Priority: -- → P3
The Schedulers/Builders need to be aware of which revision is newer...somehow... Maybe we can send the push time as a property, and then have the test schedulers/builders sort by that?
Whiteboard: [unittest][automation] → [unittest][automation][sheriff-want]
I think bug 555664 already fixed this, except for a reporting issue described in bug 782874. Please reopen if you disagree.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 555664
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.