Closed
Bug 1382818
Opened 7 years ago
Closed 7 years ago
Bug filer errors out with undefined status for contextualidentity tests
Categories
(Tree Management :: Treeherder, enhancement)
Tree Management
Treeherder
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: RyanVM, Assigned: KWierso)
References
(Depends on 1 open bug)
Details
Attachments
(1 file)
Tried to file a new bug today, got the following error instead:
"Bug Filer API returned status undefined (undefined)"
Assignee | ||
Comment 1•7 years ago
|
||
In this specific case, the failure is https://treeherder.mozilla.org/#/jobs?repo=mozilla-beta&revision=e5f14b9ae6c4c1e0ff1c430503671289120db203&filter-searchStr=bc6&selectedJob=116086814 in browser/components/contextualidentity/test/browser/browser_serviceworkers.js.
When attempting to auto-find a product/component for the failure, we first search for mozbuild metadata for that file to see if it has a recommended bug product listed.
For this file, that returns https://hg.mozilla.org/mozilla-central/json-mozbuildinfo?p=browser%2Fcomponents%2Fcontextualidentity%2Ftest%2Fbrowser%2Fbrowser_serviceworkers.js which says the product should be "DOM" and the component within that product should be "Security".
To file the bug, we need to first query bugzilla for that product/component to get the default version value to assign to the bug.
That request is to https://bugzilla.mozilla.org/rest/product/DOM?include_fields=versions which returns an empty array of products, since there actually is no "DOM" product in Bugzilla.
Two steps to fix this bug:
1) Correct the mozbuild metadata. This should file into the "Core" product, and within that, either the "Security" or "DOM: Security" component.
2) The bugfiler should probably be more specific about the error. We haven't even reached the point in filing the bug where the bug filer API is actually used.
Assignee | ||
Comment 2•7 years ago
|
||
Bug 1351464 is an amusing walk down history lane.
Baku, did I misunderstand what you meant by "DOM::Security"? Should that have been product: "Core", component: "DOM: Security"?
Depends on: 1351464
Flags: needinfo?(amarchesini)
Comment hidden (mozreview-request) |
Assignee | ||
Updated•7 years ago
|
Assignee: nobody → wkocher
Comment 4•7 years ago
|
||
mozreview-review |
Comment on attachment 8888507 [details]
Bug 1382818 - Update moz.build metadata for browser/components/contextualidentity/
https://reviewboard.mozilla.org/r/159480/#review165016
Attachment #8888507 -
Flags: review?(amarchesini) → review+
Updated•7 years ago
|
Flags: needinfo?(amarchesini)
Pushed by kwierso@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/a1cdfee7cb07
Update moz.build metadata for browser/components/contextualidentity/ r=baku
Assignee | ||
Comment 6•7 years ago
|
||
bugherder |
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Comment 7•7 years ago
|
||
Wes, great analysis in comment 1!
No rush at all, but at some point would you mind filing a bug for making the bug filer error message clearer in this case. Also, I wonder if it's worth filing a build config bug for linting the values people put?
Summary: Bug filer errors out with undefined status → Bug filer errors out with undefined status for contextualidentity tests
Assignee | ||
Comment 8•7 years ago
|
||
Filed bug 1383556 for giving a better error message. Bug 1382870 would make bug 1383556's error message more useful.
Bug 1349044 already exists for having Treeherder verify product recommendations coming from moz.build metadata is valid before we try to use it (probably crosses over with bug 1383556, honestly).
Bug 1349044 Comment 5 mentions a desire to get an in-tree task running in CI that verifies moz.build information is correct, though we'd need to be careful to only really care about the information in mozilla-central's moz.build files, since information in release branches could get outdated (though an argument could be made that we should also update the metadata in release branches as long as those branches are supported). We'd need to be careful also about hitting bugzilla's API from a job running in our CI, since that should be blocked by default. Would it need to use a recent dump of bugzilla's product list?
I suppose as a one-time fix, someone (me, I guess?) could just build up a list of all moz.build files, pull out all of the bugzilla components within them, and then check them all against a list of bugzilla's products, so we can fix any that don't match up?
Assignee | ||
Comment 9•7 years ago
|
||
(In reply to Wes Kocher (:KWierso) from comment #8)
> I suppose as a one-time fix, someone (me, I guess?) could just build up a
> list of all moz.build files, pull out all of the bugzilla components within
> them, and then check them all against a list of bugzilla's products, so we
> can fix any that don't match up?
Did this, the only ones (outside of in-tree tests of moz.build itself which include intentionally incorrect components) will be fixed in bug 1383567.
Comment 10•7 years ago
|
||
Many thanks!
You need to log in
before you can comment on or make changes to this bug.
Description
•