1382818 - Bug filer errors out with undefined status for contextualidentity tests

Status: RESOLVED FIXED

(Tree Management :: Treeherder, enhancement)

Description

[Ryan VanderMeulen [:RyanVM]]

Tried to file a new bug today, got the following error instead:
"Bug Filer API returned status undefined (undefined)"

Comment 1

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

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.

Comment 2

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

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"?

Comment 3

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

Attachment: Bug 1382818 - Update moz.build metadata for browser/components/contextualidentity/

Review commit: https://reviewboard.mozilla.org/r/159480/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/159480/

Comment 4

[Andrea Marchesini [:baku]]

Comment on attachment 8888507 [details]
Bug 1382818 - Update moz.build metadata for browser/components/contextualidentity/

https://reviewboard.mozilla.org/r/159480/#review165016

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/a1cdfee7cb07
Update moz.build metadata for browser/components/contextualidentity/ r=baku

Comment 6

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/a1cdfee7cb07

Comment 7

[Ed Morley [:emorley]]

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?

Comment 8

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

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?

Comment 9

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

(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

[Ed Morley [:emorley]]

Many thanks!