https://github.com/jmaher/alert_manager/blob/3558dee537d05526e745df60cc7a902c4f2dbed4/managed_settings.py#L2 https://github.com/jmaher/alert_manager/blob/d4a8b6c54f6d95c31b7cf574200659380155b68c/parse_news.py#L246 https://github.com/jmaher/alert_manager/search?utf8=%E2%9C%93&q=tbpl

Note the repo names are different to TBPL - they actually match the buildbot 'branch' now. See the "name" property in: https://github.com/mozilla/treeherder-service/blob/master/treeherder/model/fixtures/repository.json

Apart from the branch TBPL referred to as "Firefox", all of the others listed in managed_settings.py just require a .lower() to match the 'real' repo/buildbot name that Treeherder uses. I didn't go through and change all usages of 'tbpl' in variable/table names, since that would take ages and if one reads 'tbpl' as 'resultsdashboard' they still do make sense. The main thing is to make Alert Manager not link to TBPL, seeing as it will be going away soon.

Comment on attachment 8536250 [details] Link to Treeherder rather than TBPL r=me with the one fix mentioned on github and deployment will take place once treeherder has the popup pane available in production.

The Talos panel is now in Treeherder production, can we merge this? :-)

merged and live. Any new alerts coming in will get automatic treeherder links :)

Thanks for merging, sorry about the missing colon. Re the param change, I'm pretty sure searchQuery is the correct param - and if it doesn't work, Treeherder needs fixing, I don't think this use case should be using filter-searchStr. There have been several regressions on Treeherder prod recently. Cameron, can you confirm? (context: https://github.com/jmaher/alert_manager/commit/ee0d9e30e6ff1cb3725c87926a12aca8ae82228c)

thanks for the notes on this. I just made things work- if searchQuery is what we should use, I will be happy to switch it back and help test as needed.

Hmm, sorry for the breakage on this. I hadn't realized changing that param would have these implications. I would *prefer* to keep the param as ``filter-searchStr`` or at least to keep the ``filter-`` prefix as it's part of the logic to distinguish filter params from other params. However, if we have to make it work with ``searchQuery``, I could add a special case for it. Is that worthwhile? Or could we go forward with ``filter-searchStr``?

filter-searchStr is fine with me, it isn't very easy to remember, ideally it would be like: https://treeherder.mozilla.org/ui/#/jobs?filter=linux talos dromaeo if all usage of filter-searchStr are from programs then I don't see a problem with it.