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)
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.
Reporter | ||
Comment 1•11 years ago
|
||
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.
Comment 2•11 years ago
|
||
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.
Reporter | ||
Comment 3•11 years ago
|
||
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)
Comment 4•11 years ago
|
||
(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)
Reporter | ||
Comment 5•11 years ago
|
||
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)
Comment 6•11 years ago
|
||
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
Reporter | ||
Comment 7•10 years ago
|
||
(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 :)
Comment 8•7 years ago
|
||
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.
Description
•