Closed
Bug 611448
Opened 14 years ago
Closed 13 years ago
Buildbot JSON needs logURL field
Categories
(Release Engineering :: General, defect, P4)
Release Engineering
General
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: mstange, Assigned: catlee)
References
Details
(Keywords: buildapi, Whiteboard: [buildapi][json][logs])
Getting the URL of the log that's uploaded for a build is trickier than it should be. At the moment it's possible for most builds by connecting the packageUrl, build_url, builddir and buildnumber fields, as demonstrated here:
http://hg.mozilla.org/users/dbaron_mozilla.com/buildbot-json-tools/file/28b24c910790/filter-buildbot-json.py#l47
However, that neither works for Talos runs (no builddir field) nor for busted builds (no packageUrl or build_url field).
Summary: Bulidbot JSON needs logURL field → Buildbot JSON needs logURL field
Updated•14 years ago
|
Priority: -- → P4
Assignee | ||
Comment 1•14 years ago
|
||
The problem right now is that the log is uploaded asynchronously after the build is completed. We could pre-compute what the log url _should_ be, but if the actual log transfer fails for some reason the logUrl property wouldn't be correct. This might be a decent intermediate step to take though.
If we change how we're doing log uploading from a asynchronous status plugin that's triggered after the build is finished to a master-side step that runs as the last step, we will be able to set this property before the build is finished, so it would show up in the list of build properties as well.
Reporter | ||
Comment 2•14 years ago
|
||
(In reply to comment #1)
> The problem right now is that the log is uploaded asynchronously after the
> build is completed. We could pre-compute what the log url _should_ be, but if
> the actual log transfer fails for some reason the logUrl property wouldn't be
> correct. This might be a decent intermediate step to take though.
Yes, that would be a big step forward.
Not knowing the log filename for Talos runs and failed builds is the biggest obstacle to a Tinderbox-free TBPL at the moment.
Assignee | ||
Updated•14 years ago
|
Assignee: nobody → catlee
Priority: P4 → P2
Assignee | ||
Updated•14 years ago
|
Whiteboard: [buildapi][json]
Assignee | ||
Updated•13 years ago
|
Priority: P2 → P4
Reporter | ||
Comment 3•13 years ago
|
||
This is not urgent anymore. The Run._log function at http://hg.mozilla.org/users/mstange_themasta.com/tinderboxpushlog/file/tip/dataimport/import-buildbot-data.py seems to work pretty well.
Assignee | ||
Updated•13 years ago
|
Assignee: catlee → nobody
Comment 4•13 years ago
|
||
(In reply to Chris AtLee [:catlee] from comment #1)
> We could pre-compute what the log url _should_ be, but
> if the actual log transfer fails for some reason the logUrl property
> wouldn't be correct.
It would, however, be exactly as good as tbpl's current reverse-engineering. It also would have saved you from the backout of bug 671450, and would save me the comment I'm trying to write in bug 685299, which is a truly awful "reverse engineering of tbpl's reverse engineering of buildbot's upload path rules so that another chunk of buildbot can upload where tbpl expects it to."
Assignee | ||
Updated•13 years ago
|
Whiteboard: [buildapi][json] → [buildapi][json][logs]
Assignee | ||
Updated•13 years ago
|
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Updated•11 years ago
|
Product: mozilla.org → Release Engineering
You need to log in
before you can comment on or make changes to this bug.
Description
•