Trychooser (https://github.com/pbiggar/trychooser) is a pretty handy Mercurial extension. I'd love to be able to effortlessly submit Try builds from mach.
Thinking small, we could just go with:
$ ./mach try
Then go into the existing trychooser prompting flow.
Thinking bigger, I think it would be cool if:
$ ./mach try submit
<existing trychooser flow)
$ ./mach try submit --no-talos
<all - talos submitted without any prompting>
$ ./mach try profile foo
<prompt for and save Try settings to a named "profile"
$ ./mach try foo
<use "foo" profile to submit Try build>
$ ./mach try status
<mach remembers previously submitted try builds or looks up try builds pushed by you and displays a summary of their progress>
This may be the first part of mach/mozbuild that interacts with Mercurial. I would prefer all interaction use the Mercurial Python API directly. I'm not sure how stable their API is. Consideration should also be given to how this will work with Git.
Interaction with TBPL (e.g. ./mach try status) could be a follow-up bug. But, if someone wants to tackle it, that would be awesome.
(In reply to Gregory Szorc [:gps] from comment #0)
> This may be the first part of mach/mozbuild that interacts with Mercurial. I
> would prefer all interaction use the Mercurial Python API directly. I'm not
> sure how stable their API is. Consideration should also be given to how this
> will work with Git.
Also, licensing; I believe there are two HG APIs, and at least one is GPLed.
Also the Mercurial shipped with Mozillabuild doesn't have the API exposed in the system Python (because it's shipped as a standalone exe with its own embedded Python).
We should just kill MozillaBuild. Bug 774115 can be the beginning of that work.
What I would *actually* like, longer term, to see is a base python API for try message building which the hg extension could use (and could be bundled with) that would utilize the actual possible list of tests which would need to be stored in something parseable without massive dependencies (I'm looking at you, buildbot-configs), like a JSON file. Then anyone could make client libraries for this. That said, I am fine with incremental steps forward and integration with mach sounds in any form like a win for the time being
I would also like the ability to try patches not in the tree; e.g. from a bugzilla attachment