Closed Bug 939787 Opened 11 years ago Closed 7 years ago

[mozilla-get-url] still doesn't find reliably the latest tinderbox build

Categories

(Firefox OS Graveyard :: Gaia::TestAgent, defect)

x86_64
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: julienw, Unassigned)

Details

The current logic is: * fetch the contents of a tinderbox directory (eg ftp://ftp.mozilla.org/pub/mozilla.org/b2g/tinderbox-builds/mozilla-central-linux64_gecko/ for x64 b2g desktop) * get the latest (ie: the biggest number) that has a build But what we saw today is that the biggest number is not necessary the latest build: a newer build is [1] an older build is [2] But [2] has a bigger number. [1] http://ftp.mozilla.org/pub/mozilla.org/b2g/tinderbox-builds/mozilla-central-linux64_gecko/1384772379/ [2] http://ftp.mozilla.org/pub/mozilla.org/b2g/tinderbox-builds/mozilla-central-linux64_gecko/1384776126/ I'm currently trying to find a reliable way with ateam's guys.
Here is what I'd like to try (I analyzed the network traffic when consulting TBPL) : * fetch https://hg.mozilla.org/mozilla-central/json-pushes?full=1&maxhours=24 + order that json by key, take the greatest one + this object has a "changesets" property which is an array + take the _last_ item in this array + this is an object - its "tags" property in an array which should have the string "tip" as an item. This shows this is the latest and greatest + the "node" property contains a changeset + take the 12 first characters * then fetch https://tbpl.mozilla.org/php/getRevisionBuilds.php?branch=mozilla-central&rev=<reduced changeset> + you get another json + this json is an array + take the first item + this is an object + take the property "log" + keep the string between the last '/' and the previous '/' => congratulations, you have the build id! (fortunately, it's the same one for all builds) Then we can use that build id to go and fetch our builds in the correct directory.
That sounds fine - the only caveat is that the found changeset will not always have builds associated with it (something landed as a DONTBUILD etc) - in which case you'd need to take the second to last item from the json-pushes response, check for builds and then potentially repeat again.
Chris, Ben, how feasible could it be to have a "latest-build" link pointing to the latest directory containing a build, in each build parent directory (eg [1])? Would surely be a lot easier than implementing comment 1 with a retry mechanism as comment 2 is saying ;) [1] http://ftp.mozilla.org/pub/mozilla.org/b2g/tinderbox-builds/mozilla-central-linux64_gecko/
Flags: needinfo?(catlee)
Flags: needinfo?(bhearsum)
(In reply to Julien Wajsberg [:julienw] from comment #3) > Chris, Ben, how feasible could it be to have a "latest-build" link pointing > to the latest directory containing a build, in each build parent directory > (eg [1])? Would surely be a lot easier than implementing comment 1 with a > retry mechanism as comment 2 is saying ;) We don't really have any mechanism for doing this right now. We don't even do this sort of thing for nightly builds. The only place where we have version-less links is releases - and those are maintained by hand. That's not to say it can't be done, just that we don't have any easy of enabling it -- we'd have to build something new to do this.
Flags: needinfo?(bhearsum)
ok, then I think the best things is to file another bug for this, and carry on with comment 1 for now :) Thanks!
Flags: needinfo?(catlee)
Also, the behaviour of a latest- link for these builds probably won't give you what you want for a few reasons: - builds sometimes finish out of order e.g. build A starts before build B, but build B finishes first. when A finishes last, it will update the latest- symlink to its output, and now the symlink points to an older build - people sometimes retrigger builds on older revisions, which will end up overwriting the symlink
(In reply to Chris AtLee [:catlee] from comment #6) > Also, the behaviour of a latest- link for these builds probably won't give > you what you want for a few reasons: > > - builds sometimes finish out of order e.g. build A starts before build B, > but build B finishes first. when A finishes last, it will update the latest- > symlink to its output, and now the symlink points to an older build > > - people sometimes retrigger builds on older revisions, which will end up > overwriting the symlink It's pretty clear to me that these cases should not change the symlink. But I know this is likely more difficult than just saying it :)
Firefox OS is not being worked on
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.