1361205 - index.gecko.v2.mozilla-beta.latest.firefox.linux64-opt is pointing to a stale buildbot build

Status: RESOLVED FIXED

(Release Engineering :: General, defect)

Description

[Bob Clary [:bc] (inactive)]

index.gecko.v2.mozilla-beta.latest.firefox.linux64-opt is pointing to a stale buildbot build:

https://tools.taskcluster.net/task-inspector/#dWSIHwROQoKVClA46zIwKQ/

but index.gecko.v2.mozilla-beta.latest.firefox.linux64-debug is pointing to a current build:

https://tools.taskcluster.net/task-inspector/#UDwESiSVT2GI8GdY9Mc5gA/

Comment 1

[Bob Clary [:bc] (inactive)]

I should note that this appears to only be the case for Linux builds. Windows builds appear to be current.

Comment 2

[John Ford [:jhford] CET/CEST Berlin Time]

I checked the takscluster index and the only issues that I saw there were two single H27 connection resets a few hours ago.  Since these were independant calls and all users of the API should handle this with retrying the attempt, I don't think these two errors are related.

Since the index appears to be working, my instinct is to check on the system(s) which are inserting into the index.  Since this is a buildbot originating job, I'm going to transfer this bug to the Releng component so that someone can take a look at it.  If this is an index bug for sure, please feel free to move back to Taskcluster

Comment 3

[Justin Wood (:Callek)]

Without looking too closely at the underlying code paths, could this be related to: Bug 1360550

Comment 4

[Michael Shal [:mshal]]

I don't think it has to do with the buildids - it looks like we don't actually schedule linux64-opt tc(B) builds on mozilla-beta in Taskcluster. There is only tc(N) for opt, while we have tc(B) for debug. The N builds are under gecko.v2.mozilla-beta.nightly.latest. I'm not sure if this is intentional - maybe we only do N now because of release promotion?

Ideally we would be able to hide or remove old routes, which I believe is what bug 1150179 is for.

Comment 5

[Nick Alexander :nalexander [he/him]]

Not scheduling linux64-opt breaks artifact builds against mozilla-beta:

$ ./mach artifact install --verbose
 0:03.07 Attempting to find a pushhead containing 13ff34d820621cdaa52a9cf2dfd2a66998438bf8 on mozilla-central.
 0:03.70 Attempting to find a pushhead containing 13ff34d820621cdaa52a9cf2dfd2a66998438bf8 on integration/mozilla-inbound.
 0:04.09 Attempting to find a pushhead containing 13ff34d820621cdaa52a9cf2dfd2a66998438bf8 on releases/mozilla-beta.
 0:04.09 Retrieving the last 50 pushheads starting with id 7314 on releases/mozilla-beta
 0:04.10 Trying to find artifacts for hg revision 13ff34d820621cdaa52a9cf2dfd2a66998438bf8 on tree releases/mozilla-beta.
 0:04.10 Searching Taskcluster index with namespace: gecko.v2.mozilla-beta.revision.13ff34d820621cdaa52a9cf2dfd2a66998438bf8.firefox.linux64-opt
...
<snip>

This is simply because the job isn't scheduled, so https://tools.taskcluster.net/index/artifacts/#gecko.v2.mozilla-beta.revision.13ff34d820621cdaa52a9cf2dfd2a66998438bf8.firefox/gecko.v2.mozilla-beta.revision.13ff34d820621cdaa52a9cf2dfd2a66998438bf8.firefox doesn't have the linux64-opt route.

While investigating this, I saw a green AB build; but https://treeherder.mozilla.org/#/jobs?repo=mozilla-beta&revision=13ff34d820621cdaa52a9cf2dfd2a66998438bf8&selectedJob=99462487 doesn't even look like an artifact build!  I see no downloading of artifacts and I see gcc invocations.

Comment 6

[Aki Sasaki (not active)]

https://firefox-ci-tc.services.mozilla.com/tasks/index/gecko.v2.mozilla-beta.latest.firefox/linux64-opt wfm; resolved at some point between then and now.