1117583 - Create a minimal UI that sheriffs can use to file bugs for new intermittent failures more quickly

Status: VERIFIED FIXED

(Tree Management :: Treeherder, defect, P4)

Description

[Ed Morley [:emorley]]

The requirements for a minimum viable product were scoped in bug 1110240.
This bug is for implementing it.

Comment 1

[Ed Morley [:emorley]]

This was previously a Q1 Treeherder goal for this quarter, but has now been deferred in favour of infra/reliability/bug fixes. If anyone else wants to grab this in the meantime then go ahead :-)

Comment 2

[Ed Morley [:emorley]]

This task just got a lot simpler:

https://groups.google.com/d/msg/mozilla.dev.platform/Otk8z7wFRr4/2EolZ8jbUsEJ
===
I have plans to stand up a web service that essentially exposes `mach file-info`. This will allow anybody to query metadata without needing a full source checkout.

I've deployed an alpha version of the service at http://ec2-52-10-94-76.us-west-2.compute.amazonaws.com/. There is only one useful endpoint right now. It has the form:

    /{tree}/file-info

It accepts "f" query string arguments that define files to retrieve information on. e.g.

    http://ec2-52-10-94-76.us-west-2.compute.amazonaws.com/central/file-info?f=Makefile.in

It is currently pulling central, inbound, and fx-team at 60s intervals.

Once the server is reviewed and checked in, I'll get it deployed somewhere more permanent. For now, ping me for feature requests.

Hopefully the potential for this web service gets people thinking about the cool things that can be derived from it.
===

Comment 3

[Ed Morley [:emorley]]

The service mentioned in comment 2 is now official and documented here:
https://mozilla-version-control-tools.readthedocs.org/en/latest/hgmo/mozbuildinfo.html

:-)

Comment 4

[Ed Morley [:emorley]]

eg:
https://hg.mozilla.org/mozilla-central/json-mozbuildinfo/2c1fb007137d?p=dom/fmradio/test/marionette/test_bug862672.js

Though there's no bugzilla components returned for that result - don't know if it's broken or if that part of the repo hasn't yet had it filled in.

Also the "use a revision" feature appears broken, eg:
https://hg.mozilla.org/mozilla-central/json-mozbuildinfo/2c1fb007137d

Plus "tip":
https://hg.mozilla.org/mozilla-central/json-mozbuildinfo

Wes, I'd ask gps and see what's up.

Comment 5

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

Attachment: WIP PR 1144

Status update at the end of November:

Demo instance up and running at https://kwierso.github.io/treeherder/ui/ if anyone wants to play with it.

The current workflow is suboptimal (it gathers all of the information nicely, then opens a tab/window to bugzilla for the final submission instead of just submitting via the REST API), but it seems to work fairly well (I'll switch it to submitting via REST before I ask for review).

So the workflow at the moment goes like this:
Open Treeherder.

Select a failure.

Click the new 'bug' button next to one of the failure lines to bring up the intermittent filing UI.

The page will automatically try to find a generic product/component pair based on the top-most directory in the path contained in the failed line. (There's a massive blob of JSONy stuff in the new code pairing up top-level dirs with product/component pairs.) (This also assumes it can find a file path in the failure line.)

You can also do a quicksearch for better product/component pairs by typing into the textbox next to the "Find Product" button and then clicking the button.

Once you select a product/component, you can further edit the soon-to-be-filed bug's summary as desired.

There are checkboxes for the parsed log link, raw log link and (when it detects the failure was in a reftest) a reftest viewer link. When checked, the link will be included unedited into the soon-to-be-filed bug's comment 0. Additionally, the text next to the checkboxes will open those links into new tabs/windows so you can get additional information from the logs to add to comment 0.

You can then add whatever other content you'd like for the comment 0 in the big textbox.

The "intermittent-failure" keyword is pre-filled, and you can add whatever other comma-separated keywords you want. 

You can add a comma-separated list of emails to be Cc'd into the new bug. 

There's a currently-disabled box for similarly adding people to be needinfo'd into the bug because I haven't figured out how to pre-fill the needinfo flags.

You can add dependencies as needed for either Depends On or Blocks.

Click submit for the page to then submit the new bug information to Bugzilla. This currently means it just opens up Bugzilla's new bug form with the information from the intermittent filer form pre-filled. Once I get it to directly submit the new bug via the REST API, I'll have it return the bug number to the main Treeherder UI to automatically classify the selected failure, but for now you'll need to take the bug number and classify it yourself.







I'm interested in people's thoughts on this so far (and if you can find any cases where this is totally broken for me to fix).

My next step is to switch it to directly submit the bug via the REST API.

I've copied over the MVP requirements to an etherpad page, and added in-line comments addressing most of them: https://public.etherpad-mozilla.org/p/intermittent-filer-mvp


I would like to add some tests for all of this once everything gets finalized, but I have no idea where to even start for that. Feedback welcome on that, too. :)

Comment 6

[William Lachance (:wlach)]

(In reply to Wes Kocher (:KWierso) from comment #5)
> Created attachment 8693871 [details] [review]
> WIP PR 1144
> 
> Status update at the end of November:
> 
> Demo instance up and running at https://kwierso.github.io/treeherder/ui/ if
> anyone wants to play with it.
> 
> The current workflow is suboptimal (it gathers all of the information
> nicely, then opens a tab/window to bugzilla for the final submission instead
> of just submitting via the REST API), but it seems to work fairly well (I'll
> switch it to submitting via REST before I ask for review).

So I've been thinking about how to do something similar for Perfherder, providing an interface to let people easily file regression reports based on change notifications in performance.

I know this actually undoes a lot of your work, but I wonder if it might not be better just to remove the modal dialog altogether and just jump directly to bugzilla with all the fields filled in by default. This is what I'm planning to do for Perfherder and has at least two advantages:

1. People can tailor the bug exactly to their preferences and needs.
2. A lot less code inside Treeherder to maintain.

Yes, there's the extra step of linking to the bug once it's been filed, but I don't think that should be *that* bad. I think prefilling the bug template goes 99% of the way there in saving people time and removing guesswork from the whole process.

Comment 7

[Phil Ringnalda (:philor)]

That would only work if we had 100% perfect correspondence between test directories and bug product/components, because once you've gone to the form you've lost your chance at searching for where the bloody hell WebExtensions is, which sure isn't Firefox::General like their browser-chrome tests would make you think.

Comment 8

[William Lachance (:wlach)]

(In reply to Phil Ringnalda (:philor) from comment #7)
> That would only work if we had 100% perfect correspondence between test
> directories and bug product/components, because once you've gone to the form
> you've lost your chance at searching for where the bloody hell WebExtensions
> is, which sure isn't Firefox::General like their browser-chrome tests would
> make you think.

Perhaps a more minimal modal to just select the component makes sense, in that case.

Comment 9

[Ed Morley [:emorley]]

(In reply to Phil Ringnalda (:philor) from comment #7)
> That would only work if we had 100% perfect correspondence between test
> directories and bug product/components, because once you've gone to the form
> you've lost your chance at searching for where the bloody hell WebExtensions
> is, which sure isn't Firefox::General like their browser-chrome tests would
> make you think.

Not with the new bugzilla ui (enable in prefs, will be the default soon).

Comment 10

[Cameron Dawson [:camd]]

This looks pretty cool, Wes.  I admit, my first impression was that it would be better to open a new tab with a bugzilla form pre-filled.  (prevents duplicating the work of their form and reducing the number of things to maintain.

However, I guess the real win with this modal is that you can then (as you said) get the new bug number and auto-create the classification.  That would save quite a few clicks.

Just throwing ideas out here: If we did keep the form, and auto-created the classification, that would give us a link to that bug in bugzilla where custom tweaks could be made after the bug was created.  Perhaps you could have 3 buttons: "Cancel", "Save" and "Save and open bug".  the last would open a new bugzilla tab to any tweaking needed.

I agree with Will that minimizing the form means less code to maintain.  So decide on the minimum commonly needed fields.  (perhaps that's what you already have here).  Anything that falls into the, "we might need that sometimes" category, skip it and let them do it in Bugzilla.

But overall this is cool, and looks really handy.  At least until autoclassifying becomes perfect.  I'm sure that'll be "any day now..."  ;)

Comment 11

[Carsten Book [:Tomcat]]

Comment on attachment 8693871 [details] [review]
WIP PR 1144

Really cool work i love it, played with it and its great. Thanks Wes for doing this!

Comment 12

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

Attachment: Link to PR 1223

Github's silly rules about closed pull requests means that old PR is forever closed. Here's a new one.

I think this is finally ready for review (or at least a closer round of feedback).

This should work locally in vagrant, though you'll need to do some stuff first:

You'll need to export a new environment variable named "TREEHERDER_BUGZILLA_API_KEY", set to some bugzilla account's api key (it's currently going to submit to bugzilla-dev.allizom.org, I'll need to change that over to the official BMO instance before this lands). Since it's a dev instance, you can use my bugzilla-dev key, qF8lX6AyGjcZcmSV4tZTmy2F2PbBycQdB9lsp8cB

You'll need to add a persona account on the local instance and sign in with that account.

With that set up, run the ingestion tasks so you can get some jobs.




I'll write up more directions tomorrow, possibly even with pretty pictures.

Comment 13

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

Here's an album with some pictures of how to set things up and use the tool: http://imgur.com/a/rfauR

Comment 14

[William Lachance (:wlach)]

I upgraded the version of angular bootstrap to 0.14.3 in bug 1236732, which means you should change references to $modal -> $uibModal. See the patch there for more details.

Comment 15

[Cameron Dawson [:camd]]

Comment on attachment 8702428 [details] [review]
Link to PR 1223

kwierso: clearing the review flag rather than marking it r- because this is great stuff, but I think it would be better angularified from ``getElementById`` code to more ``$scope.foo`` code.

Comment 16

[GitHub Autolander Bot]

Attachment: [treeherder] KWierso:bug1117583serverside2 > mozilla:master

Comment 17

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

Comment on attachment 8713314 [details] [review]
[treeherder] KWierso:bug1117583serverside2 > mozilla:master

I split off the server-side part of this bug into this PR so it can be landed before/without the client side bug form getting completed. I'll update the old PR to be based on top of this in a bit.

Comment 18

[Ed Morley [:emorley]]

Comment on attachment 8713314 [details] [review]
[treeherder] KWierso:bug1117583serverside2 > mozilla:master

Stealing review to give camd a hand :-)

I've left some comments on the PR - the r- is because it currently leaks the secret key back to the user.

I also think we need some tests for the handling of the submitted fields (since the endpoint does some manipulation of the data and not just a straight submission).

Your best bet will be to use the responses package - see here for an example:
https://github.com/mozilla/treeherder/blob/375960c8437788526259ea2c1f6e042afec279a0/tests/etl/test_pushlog.py#L22

You'll also want to set a testing API key that you can check has been sent correctly when you use responses. That key can be set in:
https://github.com/mozilla/treeherder/blob/master/tests/settings.py

Comment 19

[Ed Morley [:emorley]]

(And thank you for splitting out the API addition - it will make the reviews quicker :-))

Comment 20

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

So I'm back to trying to push this to completion. :)

What would be the easiest way for me to make sure everything on the server-side component is working properly without also having the UI-side component involved? Is there some local client I can set up to submit requests (with faked versions of all of the information that the UI would normally gather and submit) to the server's new api endpoint?

Comment 21

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

This is mostly for locally testing things, not for unit tests, to be clear.

Comment 22

[Ed Morley [:emorley]]

Adding some tests would actually probably be a good first step. Other than that, you can either test locally with an additional local-only commit that has the UI parts, or else submit to the API using any of:
* curl
* a short python script using requests
* httpie (https://github.com/jkbrzt/httpie)

(Making sure to have the backend point at BMO landfill/dev instance etc).

Comment 23

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

So https://github.com/mozilla/treeherder/pull/1282 is what I have so far for adding tests, and I'm kinda stuck.

As the PR stands currently, the test I added fails, but that's only because the fake API key I added doesn't actually work on bugzilla-dev. I can't figure out how to use responses to mock out the request to bugzilla, so the test is actually going to bugzilla. If you change https://github.com/mozilla/treeherder/pull/1282/files#diff-341a01ac1bfeb1ba8b836d7a66f41522R15 to be an actual API key on bugzilla-dev, the test will successfully file a bug on bugzilla-dev and the test will pass, but that clearly isn't useful for an automated test.

Any pointers on how I can get responses to handle the call? I would've thought https://github.com/mozilla/treeherder/pull/1282/files#diff-1e89927f0bf6c552446d0d0c579fb9ccR21 would catch any request going to https://bugzilla-dev.allizom.org/ no matter what follows that '/', but it clearly isn't. I'd ask Ed, but he's out until after the end of the quarter, and I'd really like to have this wrapped up before then. :)

Comment 24

[Cameron Dawson [:camd]]

I tried this in the test:

    content = json.dumps({"success":"123456", "id": 323})
    responses.add(responses.POST,
                  'https://bugzilla-dev.allizom.org/rest/bug',
                  body=content, status=200,
                  match_querystring=False,
                  content_type='application/json')

and that seems to work.

Comment 25

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

Comment on attachment 8713314 [details] [review]
[treeherder] KWierso:bug1117583serverside2 > mozilla:master

And with that, we're off!

This no longer leaks the secret key on failure. The API key now defaults to None, and complains when an attempt to file a bug is made without having it set.

By default, the bug filer tries to use production bugzilla. The local config settings default to bugzilla-dev.

I added a couple tests. These tests default to a completely fake URL and sets a completely fake API key.

The first test creates an authenticated request to file a new bug, and the completely fake bugzilla URL is mocked out to respond with a bug ID, after checking to make sure that bugzilla.py modified the bug's information correctly (it adds a "filed by X" to the bug description so people can tell who filed the bug if more information is needed).

The second test creates an unauthenticated request to file a new bug, which fails, as expected.

I have a few other ideas for tests that I might add this week, but I'm open to suggestions for other things to test.

Sending the review request to both Ed and Cam because I'm not too picky on who reviews this, just that it gets reviewed. :)

Comment 26

[GitHub Autolander Bot]

Attachment: [treeherder] KWierso:bug1117583UIside > mozilla:master

Comment 27

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

Comment on attachment 8735690 [details] [review]
[treeherder] KWierso:bug1117583UIside > mozilla:master

And a PR for a rebased UI side. :)

This is based on top of the server-side part, just ignore everything outside of ui/ 

I just tested both parts together and it successfully created a bug over on bugzilla-dev (after exporting the key and url, and creating a user on my vagrant instance of treeherder).

Comment 28

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

Steps to test out the whole thing, using my bugzilla-dev API key:

Pull and check out the UI side PR branch.

FIRST TERMINAL WINDOW:
vagrant up
vagrant ssh
export BUGZILLA_API_URL=https://bugzilla-dev.allizom.org
export BUGZILLA_API_KEY=qF8lX6AyGjcZcmSV4tZTmy2F2PbBycQdB9lsp8cB
./manage.py createsuperuser --username "SomeName" --email "[e-mail]"
./manage.py runserver


SECOND TERMINAL WINDOW:
vagrant ssh
celery -A treeherder worker

THIRD TERMINAL WINDOW:
vagrant ssh
./manage.py ingest_push mozilla-inbound <some inbound rev within the last few hours>

<Give the worker time to ingest the push and parse the logs>


BROWSER WINDOW:
Go to the local treeherder instance
Sign in with the persona account you added
Select a failed job
See the new button in the failure summary panel
Push the button.
Interact with the new bug filer tool.

Comment 29

[Ed Morley [:emorley]]

Comment on attachment 8735690 [details] [review]
[treeherder] KWierso:bug1117583UIside > mozilla:master

Sorry for the delay - was on PTO and then at DjangoCon :-)

Comment 30

[Cameron Dawson [:camd]]

Comment on attachment 8735690 [details] [review]
[treeherder] KWierso:bug1117583UIside > mozilla:master

Hey Wes:  I'm going to clear my review on this for now.  Please let me know if you'd like some assistance with making this code more in-line with Angular.  It can be daunting, I know.  :)

Comment 31

[Cameron Dawson [:camd]]

Comment on attachment 8713314 [details] [review]
[treeherder] KWierso:bug1117583serverside2 > mozilla:master

Looks like Ed had a good observation about when you return a 400 response.  That would be good to fix.  But other than that, this all looks like an r+ to me

Comment 32

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

(In reply to Cameron Dawson [:camd] from comment #31)
> Comment on attachment 8713314 [details] [review]
> [treeherder] KWierso:bug1117583serverside2 > mozilla:master
> 
> Looks like Ed had a good observation about when you return a 400 response. 
> That would be good to fix.  But other than that, this all looks like an r+
> to me

Moved the json() into a try/except thingy and re-squashed the PR.

Comment 33

[Treeherder GitHub Bugbot]

Commits pushed to master at https://github.com/mozilla/treeherder

https://github.com/mozilla/treeherder/commit/371ec172de645c93f98b4c74da0755baba25b97d
Bug 1117583 - Add an API endpoint that creates a new bug in Bugzilla.

This endpoint receives a http POST request from the UI containing information about the bug to be filed (product, component, summary, version, description), then formats it properly as a submission to Bugzilla's REST API, using a server-side Bugzilla API key, and adding a "treeherder" comment tag.

The API then passes back either the bug ID (if the submission was successful) or Bugzilla's failure response if something went wrong.

https://github.com/mozilla/treeherder/commit/e8fc980366f7ed34c4524dc2473a5ed5be5f8b67
Merge pull request #1282 from KWierso/bug1117583serverside2

Bug 1117583 - Add an API endpoint that creates a new bug in Bugzilla.

Comment 34

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

Comment on attachment 8735690 [details] [review]
[treeherder] KWierso:bug1117583UIside > mozilla:master

Addressed most of the comments, maybe ready for some new ones. :)

Comment 35

[Cameron Dawson [:camd]]

Comment on attachment 8735690 [details] [review]
[treeherder] KWierso:bug1117583UIside > mozilla:master

Wes: clearing the review again till you can take a crack at my latest comments.  Thanks again for working to angularize this stuff.  It'll be an awesome feature.

Please reassign to me when you'd like me to take another look.  :)

Comment 36

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

Comment on attachment 8735690 [details] [review]
[treeherder] KWierso:bug1117583UIside > mozilla:master

I think I've done everything you asked in the latest review. Also addressed Ed's about changing from bugzilla-dev to BMO.

Comment 37

[Cameron Dawson [:camd]]

Comment on attachment 8735690 [details] [review]
[treeherder] KWierso:bug1117583UIside > mozilla:master

Hey Wes: There were a few more spots needing jquery replaced with angular code.  Almost there!!  :)

Comment 38

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

Okay, I believe I've addressed all of the review comments so far.

I've reworked the UI side PR a bit, and it now includes a small addition to the server-side API. You can now make a request to the Treeherder API to return what it has set as the bugzilla root url. This is to make sure that all of the client-side requests to bugzilla match up with what the server has set. Otherwise, we can hit situations where the product version request returns values that don't match the versions that the server expects when the bug creation submission is made. The only other thing I can think to do here (other than completely not allowing custom bugzilla URLs) is to have the TH server act as an intermediate for each of these requests (so the client sends an api request to the TH server, the TH server makes the same request to the Bugzilla server, then returns that information all the way back to the client), and I'd rather avoid that.


So with that out of the way, here are the steps to test this end-to-end, using bugzilla-dev and my bugzilla-dev api key:

FIRST TERMINAL WINDOW:
vagrant up
vagrant ssh
Either edit treeherder/values/settings.py or copy settings_local.example.py to settings_local.py to make sure BZ_API_URL points to bugzilla-dev
export BUGZILLA_API_KEY=qF8lX6AyGjcZcmSV4tZTmy2F2PbBycQdB9lsp8cB
./manage.py createsuperuser --username "<SomeName>" --email "<[e-mail]>"
./manage.py runserver


SECOND TERMINAL WINDOW:
vagrant ssh
celery -A treeherder worker

THIRD TERMINAL WINDOW:
vagrant ssh
./manage.py ingest_push mozilla-inbound <some inbound rev within the last few hours>

<Give the worker time to ingest the push and parse the logs>


BROWSER WINDOW:
Go to the local treeherder instance
Sign in with the persona account you added
Select a failed job
See the new button in the failure summary panel
Push the button.
Interact with the new bug filer tool.

Comment 39

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

Wondering if I should hide the "create bug" button behind a URL parameter like autoclassify is?

Comment 40

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

(In reply to Wes Kocher (:KWierso) from comment #39)
> Wondering if I should hide the "create bug" button behind a URL parameter
> like autoclassify is?

Added a commit to do just that. Happy to drop it if you trust you want this enabled by default. It does mean we'll need to set up a bugzilla account for the bugfiler and add the API key for it to Treeherder's configuration or we'd be deploying a broken feature to everyone that's signed in.

Comment 41

[Ed Morley [:emorley]]

(In reply to Wes Kocher (:KWierso) from comment #38)
> I've reworked the UI side PR a bit, and it now includes a small addition to
> the server-side API. You can now make a request to the Treeherder API to
> return what it has set as the bugzilla root url. This is to make sure that
> all of the client-side requests to bugzilla match up with what the server
> has set. Otherwise, we can hit situations where the product version request
> returns values that don't match the versions that the server expects when
> the bug creation submission is made. The only other thing I can think to do
> here (other than completely not allowing custom bugzilla URLs) is to have
> the TH server act as an intermediate for each of these requests (so the
> client sends an api request to the TH server, the TH server makes the same
> request to the Bugzilla server, then returns that information all the way
> back to the client), and I'd rather avoid that.

I think that other than for testing of this specific feature (for which someone can use local.conf.js and settings_local.py), we've never going to use a non-default Bugzilla URL, so I think fetching the Bugzilla URL from the API might be overkill.

Perhaps omit it until such a point where it becomes an issue? :-)

Comment 42

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

(In reply to Ed Morley [:emorley] from comment #41)
> (In reply to Wes Kocher (:KWierso) from comment #38)
> > I've reworked the UI side PR a bit, and it now includes a small addition to
> > the server-side API. You can now make a request to the Treeherder API to
> > return what it has set as the bugzilla root url. This is to make sure that
> > all of the client-side requests to bugzilla match up with what the server
> > has set. Otherwise, we can hit situations where the product version request
> > returns values that don't match the versions that the server expects when
> > the bug creation submission is made. The only other thing I can think to do
> > here (other than completely not allowing custom bugzilla URLs) is to have
> > the TH server act as an intermediate for each of these requests (so the
> > client sends an api request to the TH server, the TH server makes the same
> > request to the Bugzilla server, then returns that information all the way
> > back to the client), and I'd rather avoid that.
> 
> I think that other than for testing of this specific feature (for which
> someone can use local.conf.js and settings_local.py), we've never going to
> use a non-default Bugzilla URL, so I think fetching the Bugzilla URL from
> the API might be overkill.
> 
> Perhaps omit it until such a point where it becomes an issue? :-)

At the very least, I guess I should return more than just the bug id when a bug is successfully created from the api, maybe the full link to the bug?

Comment 43

[Ed Morley [:emorley]]

(In reply to Wes Kocher (:KWierso) from comment #42)
> At the very least, I guess I should return more than just the bug id when a
> bug is successfully created from the api, maybe the full link to the bug?

Apart from the rare testing cases mentioned in comment 41, are there other use-cases you had in mind for this?

It seems like it would be inconsistent to have bug numbers generated by the bug filer use one method of generating the URL, and the auto-linkification of existing bug numbers (eg commit messages) use another?

Comment 44

[Cameron Dawson [:camd]]

Comment on attachment 8735690 [details] [review]
[treeherder] KWierso:bug1117583UIside > mozilla:master

Hey man, this is looking TONS better.  Thanks so much for working with me on this.  I have a few more spots to replace JQuery with Angular, but the should be pretty easy, by comparison to what you've already done.  Just not obvious that some parent controllers are accessible to the child.

Of course, if I've made a mistake in one of my suggestions, let's chat on IRC or something.

Comment 45

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

Comment on attachment 8735690 [details] [review]
[treeherder] KWierso:bug1117583UIside > mozilla:master

Dropped the api change, we can revisit that in the future if it becomes a bigger issue.

Addressed Camd's changes. 

I'll squash/rebase all of these changes once I get signoff on them.

Comment 46

[Cameron Dawson [:camd]]

Comment on attachment 8735690 [details] [review]
[treeherder] KWierso:bug1117583UIside > mozilla:master

Awesome work!!

Comment 47

[Treeherder GitHub Bugbot]

Commit pushed to master at https://github.com/mozilla/treeherder

https://github.com/mozilla/treeherder/commit/710b529b6b2816b48c5197f0c34e876c5d71327a
Bug 1117583 - Add UI to Treeherder to use the new bug filing api (#1374) r=camd

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.

Comment 48

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

Thanks for the review! Glad this finally could get landed. This can be deployed to production as-is and no one should have to care unless they add "&bugfiler" to the URL.

Even if they do that, the tool won't work until a bugzilla account is set up for it and the api key gets added to the Treeherder server's environment.

Comment 49

[Ed Morley [:emorley]]

Well done on getting this landed - awesome work :-)

Comment 50

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

Deployed, configured, and working!