1357175 - Improve the way support for "Trigger Missing Jobs" is determined.

Status: NEW

(Tree Management :: Treeherder, enhancement, P3)

Description

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

I just landed a patch for bug 1335506 that makes Trigger Missing Jobs only show as an option for mozilla-inbound and autoland repositories. It uses a newly added $scope.triggerMissingRepos array that just contains the strings "mozilla-inbound" and "autoland". If the currentRepo name is in that array, the menu item for Trigger Missing Jobs is shown.

This works fine and solves the immediate problem of Trigger Missing Jobs being completely broken for repositories that aren't one of those two, but it would be better if that condition was from somewhere else that's easier to keep updated and better documented.

I was thinking we could maybe add a "can_trigger" (name to be bikeshedded later) property to the supported repositories in treeherder/model/fixtures/repository.json. Then we could show the menu item only for repos that have that property set to `true`.

Another option would be to somehow expose the "SETA_PROJECTS" array in https://github.com/mozilla/treeherder/blob/76fc09fd1e17fda36e65085fafdba24e5f890359/treeherder/seta/settings.py#L2-L5 to the UI, since the condition we're really checking is if SETA controls scheduling for a repository. This would be nice because there'd only be a single point in the treeherder repository to update if/when the list of SETAd repositories changes.

Comment 1

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

Ed, thoughts? Adding stuff to repository.json is an easy way to do this but we'd still need to update things in multiple places. If we could somehow expose SETA_PROJECTS to the UI, we'd only need to update one place when the list of SETAd repositories changes.

Or we could just live with the status quo since that list is unlikely to change for a while. :)

Comment 2

[Ed Morley [:emorley]]

I think the best way to expose SETA_PROJECTS is to add it as a repository property (and in fact, I suggested rwood do this as part of the PR that added it) :-)

Comment 3

[Ed Morley [:emorley]]

So part of the problem here is that currently Taskcluster retriggers are performed by making a request to the Treeherder API, which then generates a pulse message, which is picked up by mozilla-taskcluster, that then attempts the retrigger. With this approach there's no easy way to provide any feedback as to whether the retrigger succeeded.

Bug 1420482 aims to make the Treeherder retrigger perform taskcluster retriggers client side, like already occurs for backfill/custom actions etc.

At that point, I'm pretty sure the error message will be returned by the API call made in the client and shown in the UI, reducing the potential for confusion.

Comment 4

[Ed Morley [:emorley]]

Bah wrong tab.