Closed
Bug 729929
Opened 12 years ago
Closed 12 years ago
build_url property not published for peptest pulse messages
Categories
(Release Engineering :: General, defect)
Release Engineering
General
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: jgriffin, Unassigned)
References
Details
(Whiteboard: [pulse])
Attachments
(2 files)
9.23 KB,
text/plain
|
Details | |
1.57 KB,
patch
|
rail
:
review+
mozilla
:
checked-in+
|
Details | Diff | Splinter Review |
The #.finished pulse messages for peptest do not contain a log url, unlike mochitest, reftest, et al. This makes it impossible to use the messages as a basis for automation that relies on peptest log files. Attached is a complete logfile, illustrating the absent logurl.
Comment 1•12 years ago
|
||
I don't think any of our other messages contain log urls either...
Reporter | ||
Comment 2•12 years ago
|
||
(In reply to Chris AtLee [:catlee] from comment #1) > I don't think any of our other messages contain log urls either... Whoops, of course you're right. In fact, we guess the log url based on the build url. The problem with the peptest messages is that they don't contain a build url property like other unittest messages. They do contain the build url in the "sourceStamp" block, but these are hard to consume, as there are two url's present, both with the url "null", and the actual url in the "name" field. Can we get a "build_url" property added to the peptest messages? Alternately, if the sourceStamp block were fixed to specify the url in the url field and a valid name in the name field so that we could safely distinguish between multiple url's, we could use this instead.
Summary: log url not published for peptest pulse messages → build_url property not published for peptest pulse messages
Updated•12 years ago
|
Component: Release Engineering → Release Engineering: Developer Tools
QA Contact: release → lsblakk
Whiteboard: [pulse]
Comment 3•12 years ago
|
||
(In reply to Jonathan Griffin (:jgriffin) from comment #2) > Can we get a "build_url" property added to the peptest messages? (taking the teach a man to fish approach): self.installer_url will point to the url of the installer after we run the read_buildbot_config step in peptest.py. Per http://hg.mozilla.org/build/mozharness/file/e71f75b55f2e/scripts/peptest.py#l132 we get read_buildbot_config() from BuildbotMixin, and postflight_read_buildbot_config() from TestingMixin. The self.set_buildbot_property() method will allow you to set a buildbot property; you need to write it to a file before the script exits. http://hg.mozilla.org/build/mozharness/file/e71f75b55f2e/mozharness/mozilla/buildbot.py#l60 I call this in scripts/mobile_l10n.py like this: http://hg.mozilla.org/build/mozharness/file/e71f75b55f2e/scripts/mobile_l10n.py#l262 So a self.set_buildbot_property('build_url', self.installer_url, write_to_file=True) after this line here: http://hg.mozilla.org/build/mozharness/file/e71f75b55f2e/mozharness/mozilla/testing/testbase.py#l81 should, in theory, fix this bug, and will also set that property for any other scripts that use this method (soon that will include desktop unit tests and talos). postflight_read_buildbot_config() also has the bonus of not being run by anyone but production.
Reporter | ||
Comment 4•12 years ago
|
||
@aki, if that's the fix to this problem, can you write the appropriate patch?
Comment 5•12 years ago
|
||
I'm not entirely sure what goes into pulse messages, but this will set the buildbot build_url property.
Attachment #632318 -
Flags: review?(rail)
Updated•12 years ago
|
Attachment #632318 -
Flags: review?(rail) → review+
Comment 6•12 years ago
|
||
Comment on attachment 632318 [details] [diff] [review] this should set the build_url property http://hg.mozilla.org/build/mozharness/rev/647acea570ef
Attachment #632318 -
Flags: checked-in+
Comment 7•12 years ago
|
||
@jgriffin, are you seeing build_url in the pulse messages?
Comment 8•12 years ago
|
||
The patches in bug 724221 should fix the Windows portion of this bug. Otherwise we're seeing build_url in the peptest pulse messages; hooray!
Assignee | ||
Updated•11 years ago
|
Product: mozilla.org → Release Engineering
Assignee | ||
Updated•7 years ago
|
Component: Tools → General
You need to log in
before you can comment on or make changes to this bug.
Description
•