So a reasonably common scenario is that a developer pushes a job to try, they get some test failures, and then they make some changes to fix those failures. In this latter case they want to run as few jobs as possible to check that the previous failures are now addressed. I imagine this working as a mach command e.g. |mach retry|. This command would have several modes of operation: |mach retry --list| - List the last e.g. 10 try jobs submitted by the current user |mach retry $SHA| - Rerun the failures from the try push with sha1 $SHA |mach retry| - Rerun the failures from the last try push submitted by the current user In terms of implementation, treeherder client  can be used to fetch the list of try pushes for a given email address, and the list of jobs for each try push. From this data you will need to construct a trychooser-style  string that will include every job that always failed on the previous push (note that due to intermittents, jobs may be rerun on try and when they are any green job should take precedence over an orange job for these purposes, at least by default). Note that the result will not necessarily be totally minimal e.g. if mochitest-1 fails on linux32 debug and reftest-1 on linux64 opt a reasonable try string would look like try: -b do -p linux,linux64 -u reftest-1,mochitest-1 Actually submitting the push to try should reuse the machinery from |mach try|.  https://treeherder.readthedocs.org/retrieving_data.html  http://trychooser.pub.build.mozilla.org/
You need to log in before you can comment on or make changes to this bug.