If the selected failure has no search_terms defined, the bug being filed will never appear as a suggestion for classification. Warn in this case.
If the bug-to-be-filed's summary does not contain any of the selected failure's search_terms, it will never appear as a suggestion for the classification. Warn in this case. The search terms are displayed in this case so the user can see exactly what needs to be added to make the bug discoverable.
This adds a new modal form to Treeherder's UI that appears when the user clicks the new "file bug" button.
The script pulls in information about the failure and pre-fills a lot of the form. It attempts to automatically find the product/component for the soon-to-be-filed bug based on the failure's file path, and includes a search box to find other products/components.
The summary by default is the failure line that the user clicked, but the user can show all of the failure lines from the failed job if more needs to be added.
Links to the parsed log, full log and (if applicable) the reftest viewer are included by default in the bug's first comment, but the user can opt to not include them in the submission.
Additional information can be included in the first comment by adding it to the large textarea in the form.
After you click "Submit Bug", the UI sends the new bug information to the Bugfiler API, which then formats the information properly for it to submit to Bugzilla's REST API using a server-side bugzilla account. The API returns either the bug id or a failure message. If a bug id is returned, the UI selects the failure and adds the bug to the classification. If a failure message is returned, the message is displayed to the user and the form becomes re-editable and re-submittable.
Ed Morley
Cameron Dawson
KWierso