FWIW, I've found |./mach try fuzzy| to be very intuitive and kind of the best of both worlds for command-line vs GUI. I don't know what the non-fuzzy version does, but perhaps fuzzy should be the default.
On Fri, Sep 15, 2017 at 4:51 PM, Nicholas Nethercote <n.netherc...@gmail.com > wrote: > Are there docs on how to use `./mach try`? `./mach help try` doesn't give > much detail. > > Also, will https://mozilla-releng.net/trychooser/ still work? I'm > generally > more of a command line person than a GUI person, but this is one case where > I find the GUI approach far more usable. > > Nick > > On Sat, Sep 16, 2017 at 8:30 AM, Gregory Szorc <g...@mozilla.com> wrote: > > > The Try Service ("Try") is a mechanism that allows developers to schedule > > tasks in automation. The main API for that service is "Try Syntax" (e.g. > > "try: -b o -p linux -u xpcshell"). And the transport channel for making > > that API call is a Mercurial changeset's commit message plus a version > > control "push" to the "try" repository on hg.mozilla.org. > > > > As the recent "Reminder on Try usage and infrastructure resources" thread > > details, scaling Firefox automation - and Try in particular - is > > challenging. In addition, the number of workflows and variations that > > automation needs to support is ever increasing and continuously evolving. > > > > It shouldn't come as a surprise when I say that we've outgrown many of > the > > implementation details of the Try Service. Try Syntax itself is over 7 > > years old and has survived a complete rewrite of automation scheduling, > for > > example. Aspects of Try are adversely impacting the ability for > developers > > to use Try efficiently and therefore undermining our collective ability > to > > get important work done quickly. > > > > In order to put ourselves in a position to more easily change > > implementation details of the Try Service so we may deliver a better > > experience for all, we'd like to require the use of `mach try` for Try > > submissions. This will ensure there is a single, well-defined, and > > easily-controlled mechanism for submitting to Try. This will allow > greater > > flexibility and adaptability. It will provide better opportunities for > user > > messaging. It will ensure that any new features are seen by everyone > > sooner. It will eventually lead to faster results on Try for everyone. > > > > Bug 1400330 ("require-mach-try") is on file to track requiring `mach try` > > to submit to Try. > > > > The mechanism for submitting to Try has remaining relatively stable for > > years. `mach try` is relatively new - and I suspect unused by a sizeable > > population. This is a potentially highly disruptive transition. That's > why > > we're not making it immediately and why we're sending this email today. > > > > You can mitigate the disruption by using `mach try` before the forced > > transition is made and reporting bugs as necessary. Have them block > > "require-mach-try" if you need them addressed before the transition or > > "mach-try" otherwise. We don't really have a good component for `mach > try` > > bugs, so put them in TaskCluster :: Task Configuration for now and chain > > them to a tracking bug for visibility. > > > > FAQ > > > > Q: When will the transition be made? > > A: When we feel `mach try` is usable for important workflows (as judged > by > > blockers on "require-mach-try"). Also, probably not before Firefox 57 > ships > > because we don't want to interfere with that release. > > > > Q: What about old changesets? > > A: You will still be able to submit to Try using the current/legacy > > mechanism for old changesets. There will be a "flag day" of sorts on > > mozilla-central after which all Try submissions will require `mach try` > or > > nothing will get scheduled. > > > > Q: Will Try Syntax continue to work? > > A: For the foreseeable future, yes. There is a long-term goal to replace > > Try Syntax with something more automatic and less effort - at least for > > most use cases. But there are no definite plans or a timetable to remove > > Try Syntax. > > > > Q: Are there any other major changes planned? > > A: Several. People are hacking on path-based selection, `mach try fuzzy` > > improvements, moz.build-based annotations influencing what gets > scheduled, > > not using a traditional Mercurial repository for backing Try, and more. > > Some of these may not be available to legacy Try submission workflows, > > giving you additional reasons to adopt `mach try` sooner. > > > > Q: Should I be worried about this transition negatively impacting my > > workflow? > > A: As long as you file bugs blocking "require-mach-try" to make it known > > why `mach try` doesn't work for you, your voice will be heard and > hopefully > > acted on. So as long as you file bugs, you shouldn't need to worry. > > > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
