1349044 - Ensure that the recommended bug components provided by moz.build metadata are actual bugzilla components before filing bugs with them

Status: NEW

(Developer Infrastructure :: Lint and Formatting, enhancement, P3)

Description

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

Bug 1338320 added some recommended bug components for testing/web-platform/ files to the moz.build metadata.

Some of those components are actually URLs to github repos with suggestions for labels to be assigned to github issues, rather than bugzilla product/component pairs.

We need to not fail miserably if we come across one of these recommendations in the bug filer.

Comment 1

[Joel Maher ( :jmaher ) (UTC -8)]

is there a specific issue you found?

Comment 2

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

I use the recommended bug components from the metadata as part of Treeherder's bug filer tool to pick the product/component in bugzilla for filing intermittent bugs. When we hit one of these non-bugzilla recommended components, the bug filer will not file things correctly.

Comment 3

[Joel Maher ( :jmaher ) (UTC -8)]

so we would need to download the bugzilla components in-tree and then ensure all the moz.build files have proper components- this seems doable, although I am not clear on how to hack the moz.build parsing.

:gps, could you give pointers on how you would solve this?

Comment 4

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

It's more a policy question than a technical issue. I was operating on the impression that BUG_COMPONENT listings are always going to be Bugzilla components, not links to external issue trackers.

The "easy" fix (for me, to not have to do any work, but still pick up the fixes from elsewhere :) ) would be to only use actual bugzilla product/component pairs in BUG_COMPONENT in moz.build files. 

Maybe a different field could be added ("ISSUE_TRACKER_LINK", maybe?) which could be things like "https://bugzilla.mozilla.org" or "https://github.com/w3c/web-platform-tests/".


Otherwise, I can just validate the recommendations within Treeherder's bug filer before actually submitting the bug. I'm already hooked up to bugzilla's product search API, so I can just use that to make sure it finds a valid result.

Comment 5

[Gregory Szorc [:gps]]

I attempted to tackle this in bug 1137043 / https://hg.mozilla.org/users/gszorc_mozilla.com/firefox/rev/71d442b7292ce85cc842b89ae3f7498c81a8ebd2.

As you might guess from the code, my idea is to code a way to audit the metadata for correctness. Then, we can roll out a CI task for running that. This is much easier today with TaskCluster than it was when I started that code 2 years ago.

Also, yes, BUG_COMPONENT was meant to link to Bugzilla. We should differentiate between BMO and non-BMO issue trackers. If nothing else, we want the metadata easy for machines to consume. This means e.g. clients shouldn't have to code logic for determining if a value refers to BMO or something else.

Code wise, it isn't difficult to add a new metadata variable. Hard part is the bikeshed and getting it hooked up to `mach files-info`. See https://dxr.mozilla.org/mozilla-central/search?q=BUG_COMPONENT+path%3A&redirect=false for all relevant code for implementing the annotation.

Comment 6

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

Bug 1349467 could have been caught if there was a test validating the components.

Comment 7

[Cameron Dawson [:camd]]

Triage - Sebastian: Is this still a problem?

Comment 8

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

The 'urls as components' issue from comment 0 is gone, invalid bugzilla products and components are still an issue after reorganization of products or components in Bugzilla. If the product::component pair doesn't exist, the bugfiler will show the returned failure code (400?) without meaningful failure message. That failure message could be improved.

Comment 10

[Marco Castelluccio [:marco]]

We could integrate such a check into https://github.com/mozilla/relman-auto-nag.

Comment 12

[Marco Castelluccio [:marco]]

(In reply to Marco Castelluccio [:marco] from comment #10)

We could integrate such a check into https://github.com/mozilla/relman-auto-nag.

Actually, I think it'd be better to integrate it directly into the bugzilla task in CI.