1498723 - Artifact build of mozilla-central skipped inbound and used autoland but probably should have failed

Status: NEW

(Firefox Build System :: General, defect)

Description

[Ed Lee :Mardak]

I pushed to try --artifact very soon after an inbound-to-m-c merge and ran into some strange test failures:

https://treeherder.mozilla.org/#/jobs?repo=try&revision=1f3fb40cb9127490bda8ef433aebda401ebf0d97&searchStr=(bc2

TEST-UNEXPECTED-FAIL | dom/serviceworkers/test/browser_antitracking.js | Test timed out -

This new test and cpp fix introduced in bug 1495285 makes the test not crash to pass, and it landed on inbound.

Looking at the build log, it looks like build grabbed an artifact from autoland:

https://treeherder.mozilla.org/logviewer.html#?job_id=205137841&repo=try

> Attempting to find a pushhead containing f2d7836b93f9ad88ef27388df27be1e6510bcdb8 on mozilla-central.
> Attempting to find a pushhead containing f2d7836b93f9ad88ef27388df27be1e6510bcdb8 on integration/mozilla-inbound.
> Attempting to find a pushhead containing f2d7836b93f9ad88ef27388df27be1e6510bcdb8 on releases/mozilla-beta.
> Attempting to find a pushhead containing f2d7836b93f9ad88ef27388df27be1e6510bcdb8 on integration/autoland.
> Retrieving the last 50 pushheads starting with id 70881 on integration/autoland
> Retrieving the last 50 pushheads starting with id 108883 on integration/mozilla-inbound
> Retrieving the last 50 pushheads starting with id 34839 on mozilla-central
> Installing from remote pushhead bb32faa290f0b8871c7c72798dc1876b01e48a31 on integration/autoland

Where the commit history for mozilla-central looks like:

o f2d7836b93f9 m-c commit
|
o ede21c2f2f99 inbound-to-m-c including bug 1495285
|
o 7fd59dc00149 autoland-to-m-c
 \
  o bb32faa290f0 last commit on autoland

https://hg.mozilla.org/mozilla-central/graph/f2d7836b93f9

I'm guessing the inbound-to-m-c commit was still building and didn't have an artifact, but maybe the whole build should have failed instead of thinking the one from autoland missing all the changes from inbound would be sufficient.. ???

Comment 1

[Chris Manchester (limited bugmail, email directly)]

This is an inherent limitation of the current implementation of artifact builds: we try to find the most recent artifacts available, the "most recent" as defined by hg, and without respect to the changes that may be present in the interim. The alternative would probably be to force fetching artifacts from exactly the revision the local tree is based on, however this might lead to more failures depending on the difference between when a revision was pushed to automation and pulled locally.