`mach try` is basically just a wrapper around try syntax, with
the added ability to specify paths to directories you want to
add tests for. It suffers the same lack of documentation that
try syntax in general does.
Trychooser now generates `mach try` command lines in addition to
commit message syntax, so given that try syntax is supposed to
continue to work with `mach try`, I don't see why trychooser
wouldn't.
On Sat, Sep 16, 2017 at 09:51:41AM +1000, Nicholas Nethercote 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
--
Kris Maglione
Senior Firefox Add-ons Engineer
Mozilla Corporation
He hoped and prayed that there wasn't an afterlife. Then he realized
there was a contradiction involved here and merely hoped that there
wasn't an afterlife.
--Douglas Adams
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
