On 2016-07-01 06:10 AM, Mike Hommey wrote:
On Fri, Jul 01, 2016 at 03:07:43PM +1000, Xidorn Quan wrote:
On Fri, Jul 1, 2016 at 1:02 PM, Karl Tomlinson <mozn...@karlt.net> wrote:
William Lachance writes:
As part of a larger effort to improve the experience around
debugging intermittents, I've been looking at reducing the time it
takes for common "try" workloads for developers (so that
e.g. retriggering a job to reproduce a failure can happen faster).
Also, accounts of specific try workloads of this type which are
annoying/painful would be helpful. :) I think I have a rough idea
of the particular type of try push I'm looking for (not pushed by
release operations, at least one retrigger) but it would be great
to get firsthand confirmation of that.
One thing that might be helpful is enabling running only tests on
try with a designated build that has already been created.
Often tests are modified to add logging, after which the same
build could be run with the new version of the test, thus saving
waiting for a build.
FWIW, there's a bug about this:
https://bugzilla.mozilla.org/show_bug.cgi?id=1240644
You can already run tests with arbitrary test tarballs (that you could
create locally), but I can't find where it's documented, which may
explain why it's not well known.
(CCing Armen, who would know)
Mike
I totally missed this.
It requires checking out mozci and using the trigger.py script (only
Buildbot - old CI).
We want to teach |mach try| to help developers with this case scenario.
It would work with both Buildbot and TaskCluster (new CI).
regards,
Armen
--
Zambrano Gasparnian, Armen
Automation & Tools Engineer
http://armenzg.blogspot.ca
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
