On 9/14/17 5:47 PM, Kris Maglione wrote:
Could we make it non-enumerable and add a counter to the window binding
resolve hook?
We could. Note that it would also trigger on sets of "window.content"
or on "var content" and so forth, though... Not clear how useful the
resulting data would be,
Your best bet is probably to use `mach try` with a specific set
of test directories. It will generate a set of --try-test-paths
flags to restrict tests to those paths, and only run the first
chunk of any group. Without that, groups shift around too much
to be reliable.
On Fri, Sep 15, 2017 at
[You can read a version of this with better formatting on my blog:
https://ehsanakhgari.org/blog/2017-09-15/quantum-flow-engineering-newsletter-24
]
Hi everyone,
I hope you're not tired of reading these newsletters so far. If not, I
applaud your patience with me in the past few months. But next
2017-09-14 18:32 GMT-04:00 Botond Ballo :
> I think "-p all" is still useful for "T pushes" (and it sounds like
> build jobs aren't the main concern resource-wise).
Correct -- all builds are in AWS.
I'd like to steer this away from "What legacy syntax should we use
instead?" and "How should we tw
On Thu, Sep 14, 2017 at 4:54 PM, Mike Hommey wrote:
> Maybe it's time to kill the `all` flag, at least for -p. Why? For the
> combined reason that you're saying we shouldn't be using it, and that
> it's actually *not* running every platform.
I think "-p all" is still useful for "T pushes" (and it
On Thu, Sep 14, 2017 at 05:37:58PM -0400, Boris Zbarsky wrote:
On 9/14/17 5:33 PM, Ehsan Akhgari wrote:
I think either of these two ideas would be good, but I think
unshipping in 57 is premature without having an understanding of how
much the Web depends on this for UA sniffing.
OK. Do you ha
On 9/14/17 5:33 PM, Ehsan Akhgari wrote:
I think either of these two ideas would be good, but I think unshipping
in 57 is premature without having an understanding of how much the Web
depends on this for UA sniffing.
OK. Do you have any suggestions on how we could gain that understanding?
We
On 09/13/2017 10:34 AM, Mike Taylor wrote:
On 9/12/17 5:04 PM, Boris Zbarsky wrote:
We could also delay the removal to after 57 to mitigate 57 risk
Or remove it for non-RELEASE_OR_BETA builds for a release or two to see
what shakes out in Nightly/DevEdition reports.
I think either of these
On Thu, Sep 14, 2017 at 11:35:53AM -0400, Stuart Philp wrote:
> Hello all,
>
> As we near 57 the Firefox CI group felt it was important to send out a bit
> of a reminder regarding infrastructure usage when you push.
>
> *tl;dr* There is a real cost (both time and $) to using the 'all' flags in
>
And if there are any unexpected-visible tasks, we stand ready to fix
that either in the tier settings or during Treeherder ingestion. Let
us know.
Dustin
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev
We chatted about this yesterday in #taskcluster on IRC. But the tier settings
for Taskcluster run jobs are being uplifted so they’re set to Tier-3 to hide.
And the ones that are still BuildBot have been audited so that they’re set as
Tier-3 in the Treeherder data ingestion process.
So the sho
You can try ActiveData, which stores all test results from the past few
weeks. Here is an example query that shows the chunk number for each
run/build combo in the past day. ActiveData is sometimes more than a
day behind
https://activedata.allizom.org/tools/query.html#query_id=4HHuBgDu
{
"
On Thu, Sep 14, 2017 at 6:13 PM, Andrew Halberstadt
wrote:
> Yes, all mochitests except Android restart between manifests (which is
> usually the same as folders).
Thank you very much, that's really useful to know and will allow me to
save some infra time!
Yes, all mochitests except Android restart between manifests (which is
usually the same as folders).
On Thu, Sep 14, 2017 at 12:03 PM Marco Bonardo wrote:
> On Thu, Sep 14, 2017 at 5:56 PM, James Graham
> wrote:
> > On 14/09/17 16:48, Marco Bonardo wrote:
> > mach try -p linux64
>
> Afaict, th
That’s correct, yeah. If you don’t have a push where it’s failed already, then
it won’t show in the Test Centric UI. Though I’ll write up a bug to explore
adding this functionality. Perhaps there’s a way to mine Active Data to get
this.
-Cam
> On Sep 14, 2017, at 9:05 AM, Gijs Kruitbosch w
This only works once you have a run that failed the test you're
interested in, right? There's no way to tell the test-centric UI "find
me the chunk for test with name X".
~ Gijs
On 14/09/2017 16:55, Cameron Dawson wrote:
Marco— I don’t know of a way to do exactly that yet. But that is in th
There's sort of a way to do this with try syntax. I say sort of because it
doesn't support all suites and there seems to be a few bugs with it. But
you can try:
./mach try -b o -p linux64 -u none path/to/dir/or/test
This should only run the directory or test you specified (it'll always show
up as
On Thu, Sep 14, 2017 at 5:56 PM, James Graham wrote:
> On 14/09/17 16:48, Marco Bonardo wrote:
> mach try -p linux64
Afaict, that runs a single folder, but the intermittent may be caused
by interactions across different tests in different folders. I'm not
up-to-date to what we do today, do we re
On 14/09/17 16:48, Marco Bonardo wrote:
When I need to retrigger a mochitest-browser test multiple times (to
investigate an intermittent), often I end up running all the
mochitest-browser tests, looking at every log until I find the chunk
where the test is, and retrigger just that chunk. The chun
Marco— I don’t know of a way to do exactly that yet. But that is in the
roadmap for the Test-based UI in Treeherder. And the existing UI may help you
there.
On any push, click the down arrow (Action Menu) at the far right of the push
status line and select “Experimental: Test-Centric UI”
Fro
> On 14 Sep 2017, at 17:48, Marco Bonardo wrote:
>
> When I need to retrigger a mochitest-browser test multiple times (to
> investigate an intermittent), often I end up running all the
> mochitest-browser tests, looking at every log until I find the chunk
> where the test is, and retrigger just
When I need to retrigger a mochitest-browser test multiple times (to
investigate an intermittent), often I end up running all the
mochitest-browser tests, looking at every log until I find the chunk
where the test is, and retrigger just that chunk. The chunk number
changes based on the platform and
Hello all,
As we near 57 the Firefox CI group felt it was important to send out a bit
of a reminder regarding infrastructure usage when you push.
*tl;dr* There is a real cost (both time and $) to using the 'all' flags in
pushes. They are there if you need them, but please remember to think about
Hi,
as part of the Thunderbird Xpcshell test suite we're running many M-C
Xpcshell tests. On Mac debug we're seeing:
TEST-UNEXPECTED-FAIL | dom/push/test/xpcshell/test_permissions.js |
xpcshell return code: -11
PID 6475 | Assertion failure: 0 == rv, at
/builds/slave/tb-c-cen-m64-d-00
On Thu, Sep 14, 2017 at 12:38 AM, Mike Hommey wrote:
> We could also move the main thread loop to a thread that we create with
> a stack size we want, and leave the original main thread just waiting
> for it (joining it).
What kind of pitfalls are associated with this approach? Could Windows
itse
On Thu, Sep 14, 2017 at 9:23 AM, Henri Sivonen wrote:
> Is there a reason why a larger stack size is OK on 32-bit Linux but
> wouldn't be OK on 32-bit Windows? (Seems kinda weird that both
> defaults would just happen to be exactly perfect even when they are so
> different.)
https://msdn.microsof
On Thu, Sep 14, 2017 at 8:23 AM, Henri Sivonen wrote:
> Do I understand correctly that this is an address space issue only and
> Windows doesn't actually physically map the pages belonging to the
> stack until they are written to? That is, do I understand correctly
> that there's no obstacle for
27 matches
Mail list logo
