Re: Adopting the black Python code style

No, black now has a `--skip-string-normalization` flag, which I would be all for using in our code base. Not sure if that was the plan here or not. -Andrew p.s It took a great deal of convincing from the community to get this flag added, as the maintainers precisely wanted to prevent conversation

Re: Adopting the black Python code style

Thanks for driving this Ricky! I'm *very* excited for it. Just want to call out that you can use: $ ./mach lint -wo --fix to reformat all the files you have touched (either in the working directory or outgoing commits). For more usage docs, see: https://firefox-source-docs.mozilla.org/code-quali

Fast tab completion for mach

I'm pleased to announce fast mach tab completion for bash, zsh and fish shells! Follow the directions here to get set up: https://firefox-source-docs.mozilla.org/mach/usage.html#tab-completion These scripts have a couple big advantages over the old completion script

Re: A new testing policy for code landing in mozilla-central

On Tue, Sep 15, 2020 at 12:28 PM Andrew McCreight wrote: > I don't know that tests being an official requirement relieves the burden of guilt of asking for tests, as everybody already knows that tests are good and that you should always write tests I think this is largely true at Mozilla, but we

Re: A new testing policy for code landing in mozilla-central

This change is fantastic, thanks for driving it! Reviewers should not need to feel bad about asking authors to go back and add tests, making this official policy removes that burden of guilt (just like how reviewbot removes the burden of pointing out linting nits). Authors can now grumble at the p

Re: Visual Studio Code integration with `clangd` for C/C++ development

This is great, thanks Andi! Are there any plans to introduce a `mach lint` integration as well? Or is that what is already being used for "inline parsing errors with limited auto-fix hints"? On Thu, Sep 10, 2020 at 12:20 PM Andi-Bogdan Postelnicu wrote: > TLDR: VSCode users can type `./mach id

Re: Intent to change default try selector from `syntax` to `auto` (ACTION NEEDED for try syntax users)

This change has now merged to central. If you see errors about unrecognized arguments when running |mach try|, you'll need to follow one of the options above. On Mon, Jul 6, 2020 at 12:33 PM Andrew Halberstadt wrote: > Hello everyone, > > On Friday July 10th we intend to change t

Intent to change default try selector from `syntax` to `auto` (ACTION NEEDED for try syntax users)

Hello everyone, On Friday July 10th we intend to change the default try selector from "syntax" to "auto". This means running `mach try` (with no subcommand) will invoke `mach try auto` rather than `mach try syntax`. If you don't use try syntax, this change will not impact your workflow. If you d

Re: Shutting down legacy Taskcluster deployment

On Fri, Jun 26, 2020 at 3:14 PM Jeff Muizelaar wrote: > What percentage of the space used for artifacts is actually builds > that are used for mozregression vs other stuff (like debug builds)? Is > there a way that we could somehow have different expiraries for the > different kinds of data? 1 ye

PSA: Precise test scheduling with |mach try auto|

*tl;dr**: Your |mach try auto| pushes can now precisely schedule relevant manifests, catching more regressions with fewer resources.* I'm happy to announce an important new capability that has been added to our CI infrastructure: scheduling specific test manifests. We've been building a machine l

Re: Feedback requested: mach try auto

er`. I filed bug 1635921 <https://bugzilla.mozilla.org/show_bug.cgi?id=1635921> to keep track of this idea. Thanks! On 5/6/20 6:55 AM, Andrew Halberstadt wrote: > > Hello everyone, > > > > A handful of us have been hard at work on an initiative to become smarter >

Feedback requested: mach try auto

Hello everyone, A handful of us have been hard at work on an initiative to become smarter about which tests we schedule for a given push. We are approaching our first major milestone, a try selector that can automatically pick which tests are most relevant to your push on your behalf. You can use

PSA: Expect decision task bustage from pushes using |mach try again| after pulling central

Hey everyone, Bug 1496768 changed the format of try_task_config.json, the mechanism we use to pass context surrounding your try pushes to the decision task. Since `mach try again` works by saving generated `try_task_configs` in a history file,

Re: Opt your try pushes into Pernosco

On Mon, Nov 25, 2019 at 1:33 PM Kyle Huey wrote: > > On Mon, Nov 25, 2019 at 10:16 AM Valentin Gosu > wrote: > >> I only have push permissions on my @gmail account, not on my @mozilla.com >> one. >> Does this mean I can't trigger a --pernosco try build, or that I need to >> log with my @moz emai

Opt your try pushes into Pernosco

Hi everyone, As of now, you can opt-in to Pernosco analysis on your try pushes by running: $ ./mach try fuzzy --pernosco or: $ ./mach try chooser --pernosco For those who are unaware, Pernosco is a debugging service built on top of rr. It will analyze your try push for fai

Re: Upcoming changes to hg.mozilla.org access

Very nice! Does this mean mozilla-inbound is effectively decommissioned at this point? Are there any circumstances it will need to run things in CI beyond November 14th? -Andrew On Fri, Nov 1, 2019 at 4:39 PM Kim Moir wrote: > The Engineering Workflow team enabled a hook in July which asked p

Re: Taskcluster log fetching

On Thu, Oct 17, 2019 at 12:59 PM Tom Ritter wrote: > I wrote a similar thing, not nearly as friendly, that takes a taskgroupid: > https://gist.github.com/tomrittervg/9e99de9b3c517b8ba4e87d2a86985616 > > It seems like there should be some better platform for communicating these > types of tools. >

Re: PSA: Improvements to infrastructure underpinning `firefox-source-docs`

We have some *very* basic documentation here: https://firefox-source-docs.mozilla.org/#managing-documentation But it's not good enough and is missing all of the features outlined here. I've filed bug 1576912 to make these docs better. Shivam a

Re: PSA: Improvements to infrastructure underpinning `firefox-source-docs`

?id=1535452> alias. If you would like to attempt to restructure your docs using these new tools, please file a bug and make it block bug 1513821 <https://bugzilla.mozilla.org/show_bug.cgi?id=1513821>. Thanks! On Tue, Aug 27, 2019 at 11:24 AM Andrew Halberstadt wrote: > Documentatio

PSA: Improvements to infrastructure underpinning `firefox-source-docs`

Documentation is hard. It's difficult to write, difficult to find and always out of date. That's why we implemented our in-tree documentation system that underpins firefox-source-docs.mozilla.org. The documentation lives next to the code that it documents, so it can be updated within the same commi

Re: Support for annotating intermittent tests with multiple statuses

Excellent work Nikki! This will give us more tools to help with the war on orange. Are there plans (or at least bugs on file) to support other harnesses? On Thu, Jul 25, 2019 at 2:47 PM James Graham wrote: > In general the order of priority is: > * First try to fix the underlying issue > * If th

PSA: Avoid |mach try| task generation by running it in the background

If you use |mach try fuzzy| or |mach try chooser|, you've probably noticed the line: *Task configuration changed, generating target task set* Followed by a 20-30 second delay as we rebuild the taskgraph locally. I just landed a change in bug 1546757

Re: Intent to remove "-e10s" from treeherder group symbols and task labels

Wed, Apr 10, 2019 at 9:40 AM Andrew Halberstadt wrote: > I had about 5 independent suggestions of "-sp" and I agree that it is much > better than "-fc". But another idea that came out of these conversations > was "1proc" which also ticks all the boxes (only be

Re: Intent to remove "-e10s" from treeherder group symbols and task labels

han "-sp". I think I'll go with that one. Thanks to everyone for all the feedback! -Andrew On Wed, Apr 10, 2019 at 4:36 AM Jonathan Kew wrote: > On 09/04/2019 20:44, Andrew Halberstadt wrote: > > Yeah, I did consider "non-e10s" for awhile and maybe it is the b

Re: Intent to remove "-e10s" from treeherder group symbols and task labels

nstead of "e10s". None of those are terribly compelling, but it's still enough to make me prefer "-fc". On Tue, Apr 9, 2019 at 3:34 PM Sylvestre Ledru wrote: > > Le 09/04/2019 à 21:26, Andrew Halberstadt a écrit : > > Hi everyone, > > > > Almost

Intent to remove "-e10s" from treeherder group symbols and task labels

Hi everyone, Almost all of our tasks in CI now run with e10s enabled, we only run non-e10s with Fennec and Linux32. Yet the "default" state in terms of our CI, is still non- e10s. You can see this by the presence of "-e10s" suffixes in task labels and treeherder symbols. To better reflect reality

PSA: Define and share |mach try| presets in-tree

Hello all, Just a quick heads up that you can now define and share try presets in-tree by adding them to this file: https://searchfox.org/mozilla-central/source/tools/tryselect/try_presets.yml There are a few presets in there that make it easy to copy from, but the gist is any name defined in tha

Re: Important: Update to latest central before running |mach try|

1531364 <https://bugzilla.mozilla.org/show_bug.cgi?id=1531364>. However the solution is tricky and I suspect not many people will run into this. So if you see this please ping me or comment in the bug and I'll help sort you out. On Tue, Feb 26, 2019 at 3:06 PM Andrew Halberstadt wrote: > If

Important: Update to latest central before running |mach try|

If you don't have any |mach try| presets for the syntax selector, feel free to ignore. Otherwise, make sure you update to the latest central before running |mach try| or you might lose your presets. If you see a message like this in your |mach try| output: *warning: unknown section 'syntax', the f

Mach's bash completion now completes arguments and subcommands

Hi everyone, Just a quick note that the bash completion script that ships with mach now completes subcommands and arguments. Previously it would only complete the main set of commands. This should help with discoverabili

Re: Proposal to adjust testing to run on PGO builds only and not test on OPT builds

CC Callek How will this interact with the "shippable builds" project that Callek posted about awhile back? My understanding is there's a high probability PGO is going away. Would it make sense to wait for that to project to wrap up? -Andrew On Thu, Jan 3, 2019 at 11:20 AM jmaher wrote: > I wou

Re: Upcoming changes to our C++ Coding Style

I think we should implement a) and do the formatting prior to submission. This prevents us from wasting reviewer time on format issues, and also makes sure that "what you see in phab, is what gets landed". On Fri, Dec 7, 2018, 2:04 PM Gregory Szorc, wrote: > On Fri, Dec 7, 2018 at 1:57 PM Botond

Re: Lando: Commit Series Landing Support Beta

This is awesome, thanks! Looking forward to trying it out. On Tue, Sep 18, 2018 at 12:29 PM Steven MacLeod wrote: > Lando support for pushing a series of commits from a Phabricator stack has > been live for the past week or so. Anyone who would like to test & provide > feedback is welcome to sta

PSA: Semantic changes to lint 'warnings'

As of bug 1460856, mozlint (the library underpinning our various lint systems) will no longer display warnings by default. All current linters which were previously emitting warnings have been changed to the 'error' level, so this won't cause any loss of coverage. There are different implications d

Re: PSA: mercurial-setup becomes vcs-setup and adds support for git

This is awesome, thanks for working on it! I filed a follow-up to detect the vcs automatically (bug 1484243). In the meantime, if you are a git user you can create an alias in ~/.mozbuild/machrc: [alias] vcs-setup = vcs-setup --git On Fri, Aug 17, 2018 at 3:51 AM Panos Astithas wrote: > Hi all,

Re: ./mach try fuzzy: A Try Syntax Alternative

I recently added the ability to specify --query multiple times (where the set of tasks is the union of each individual query). So something like: ./mach try fuzzy -q "'android !pgo !cov" -q "'build !pgo !cov" Should also accomplish what you want. It's still a bit clunky as multiple queries don't

PSA: Re-run old (non-syntax) try pushes with |mach try again|

While |mach try fuzzy| is generally a better experience than try syntax, there are a few cases where it can be annoying. One common case was when you selected a bunch of tasks in the interface and pushed. Then at a later date you wanted to push the exact same set of tasks again. This used to be a r

Re: PSA: Automated code analysis now also in Phabricator

Congrats, thanks to everyone involved for getting this working! I really like the idea of comparing errors with and without the patch, this would let us lint code where linting isn't explicitly enabled in mach lint/CI. One caveat to doing is that the review bot would need to make it very clear whi

Re: PSA: pay attention when setting multiple reviewers in Phabricator

It might be worth investigating whether we can switch Phabricator's default (so that multiple reviews are all blocking, and to make them non-blocking would require the extra step). Personally I think setting multiple reviewers up on a first come first serve is disrespectful to those reviewers' time

Re: OrangeFactor/Intermittent Failures View Update

ew On Wed, Jun 6, 2018 at 8:34 AM Andrew Halberstadt wrote: > Thanks for all your work here, this looks much cleaner and easier to > interpret. Looking forward to the future improvements you mentioned! > > For anyone bad at remembering URLs, you can get to this view by clicking > the

Re: PSA: Setting preferences and extensions in test harnesses

On Wed, May 16, 2018 at 11:07 AM Andreas Tolfsen wrote: > Any plans to consolidate the Mn preferences, currently stored in > geckoinstance.py? > Yes, but I don't have a timeline. I want to at least finish up reftest and xpcshell first. Then time permitting, I'd like to finish up marionette, cppu

PSA: Setting preferences and extensions in test harnesses

tl;dr - You can now set prefs and install extensions across multiple harnesses by modifying the relevant profile under testing/profiles. If you previously would have set a pref in: testing/profiles/prefs_general.js, Use this instead: testing/profiles/unittest/user.js # Overview I'm currently

Re: Removing tinderbox-builds from archive.mozilla.org

Going back to the original question, it looks like mozregression doesn't use the builds that Nick wants to remove anyway. So regardless of our retention policies, it looks like removing these builds would have no impact on mozregression's effectiveness. Is that an accurate statement? -Andrew On W

PSA: Default log format changed for testing commands

You should notice a new colourized log format when running tests with |mach test| or |mach mochitest|. If you want to revert to the old log format you can add: [test] format=tbpl to your ~/.mozbuild/machrc. If you have any feedback or issues with the new format, please chime in to bug 1445624

Re: overly strict eslint rules

Not replying to anyone specifically, but Sylvestre's team is working on getting our linters hooked up to mozreview/phabricator as well. I think this paired with bootstrapping the hooks will smooth out the lint fixing workflow considerably. Andrew On Fri, Jan 5, 2018 at 5:58 AM Mark Banner wrote

Re: Intent to require Python 3 to build Firefox 59 and later

On Fri, Nov 10, 2017 at 9:44 PM David Burns wrote: > My only concern about this is how local developer environments are going > to be when it comes to testing. While I am sympathetic to moving to python > 3 we need to make sure that all the test harnesses have been moved over and > this is someth

Re: Intent to Enable: Automated Static Analysis feedback in MozReview

On Tue, Oct 17, 2017 at 4:00 PM wrote: > Those things can be encoded as regexps, but they span across programming > languages (XUL, XHTML, HTML, XBL, DTD, JS, C++). > To create a new regex-based linter, simply add a file like this: https://dxr.mozilla.org/mozilla-central/source/tools/lint/test-d

Re: --verify option added to mochitest, reftest, xpcshell test harnesses

This is really great Geoff! Hopefully it can cut down the number of new intermittents we introduce to the tree. Do you know if orangefactor or ActiveData can track the rate of new incoming intermittents? Would be neat to see how much of an impact this tool has on that. On Mon, Oct 2, 2017 at 1:08

Re: Intent to require `mach try` for submitting to Try

Interesting, please file a bug either way and CC me. It worked for me back when it first landed, though I haven't tried it since. I'll see if I can reproduce sometime this week. On Sat, Sep 16, 2017 at 4:31 AM Marco Bonardo wrote: > I have a problem with try fuzzy, not sure if it's just my syste

Re: Intent to require `mach try` for submitting to Try

Yes, we'd like to make it the default eventually. I've been holding off for now, but expect it will be switched to the default at some point in Q4 or Q1. If you don't want to wait and are tired of typing 'fuzzy' each time, you can create a ~/.mozbuild/machrc file and add: [try] default = fuzzy On

Re: Reminder on Try usage and infrastructure resources

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

Re: Reminder on Try usage and infrastructure resources

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

Re: Intermittent oranges and when to disable the related test case - a simplified policy

On Mon, Sep 11, 2017 at 10:33 PM Robert O'Callahan wrote: > On Tue, Sep 12, 2017 at 11:38 AM, Andrew Halberstadt < > ahalberst...@mozilla.com> wrote: > >> I don't think so, that data already exists and is query-able from >> ActiveData: >> https://activ

Re: Intermittent oranges and when to disable the related test case - a simplified policy

On Fri, Sep 8, 2017 at 7:10 PM Gregory Szorc wrote: > I know we've topic in this topic in the past but I can't recall outcomes. > Is it worthwhile to define and use a richer test manifest "schema" that > will facilitate querying and building dashboards so we have better > visibility into disabled

Re: ./mach try fuzzy: A Try Syntax Alternative

On Sat, Sep 2, 2017 at 1:00 PM Randell Jesup wrote: > >+to...@lists.mozilla.org > > > >There have been a bunch of new features added here I'd like to highlight: > > > - --env: You can now set environment variables in your tasks directly > > from the command line, e.g: > > - ./mach try fu

Re: ./mach try fuzzy: A Try Syntax Alternative

artifact builds. There are bugs on file to reach parity here. On Wed, Aug 2, 2017 at 10:30 AM Andrew Halberstadt wrote: > I'm pleased to announce an alternative method for scheduling tasks on try > is now landed on mozilla-central. It makes use of the awesome fzf [1] > project t

Re: ./mach try fuzzy: A Try Syntax Alternative

h -q so it's in your shell history) -Andrew On Wed, Aug 2, 2017 at 10:30 AM Andrew Halberstadt wrote: > I'm pleased to announce an alternative method for scheduling tasks on try > is now landed on mozilla-central. It makes use of the awesome fzf [1] > project to filter down t

Re: disabled non-e10s tests on trunk

We now have the ability to set prefs from a mochitest manifest (see bug 1328830 and my recent newsgroup post). We could refactor these tests into a special non-e10s manifest that sets browser.tabs.remote.autostart=false and keep running them as

PSA: Set prefs in mochitest manifests

Bug 1328830 recently landed and has added the ability to set prefs directly in a mochitest manifest. Prefs can be set like this: [DEFAULT] prefs = browser.newtabpage.introShown=true layout.css.servo.enabled=true [browser_foo.js] [brow

Re: ESlint rule 'no-arbitrary-setTimeout' enabled on xpcshell tests

This is now also enabled on browser-chrome tests. Bug 1389234 has been filed to track deprecating SimpleTest.requestFlakyTimeout on mochitest-plain and chrome in favour of this new rule. -Andrew On Fri, Jul 28, 2017 at 12:02 PM Andrew Halberstadt < ahalberst...@mozilla.com> wrote: > Ah

Re: reducing high try macosx pending counts

Using the new |mach try fuzzy| selector will also make it a lot easier to only schedule exactly what you need. To run what the above try syntax uses, do: $ ./mach try fuzzy !osx 'web-platform That will run every task that doesn't contain the string 'osx', and does contain the string 'web-platfor

./mach try fuzzy: A Try Syntax Alternative

I'm pleased to announce an alternative method for scheduling tasks on try is now landed on mozilla-central. It makes use of the awesome fzf [1] project to filter down the list of all task labels with a fuzzy matching algorithm. It works both with mercurial or git. If using mercurial, you'll need t

Re: ESlint rule 'no-arbitrary-setTimeout' enabled on xpcshell tests

ble to use non-0 > timeouts. > > Cheers, > Felipe > > On Fri, Jul 28, 2017 at 12:48 PM, Andrew Halberstadt < > ahalberst...@mozilla.com> wrote: > >> As part of a larger effort to reduce oranges, we are starting to lint our >> tests for common causes of intermit

ESlint rule 'no-arbitrary-setTimeout' enabled on xpcshell tests

As part of a larger effort to reduce oranges, we are starting to lint our tests for common causes of intermittent failures. One low-hanging fruit is preventing setTimeout with an arbitrary value (aka non-zero) as opposed to waiting for an appropriate event. The mochitest harness already prevents th

Re: Linting for common causes of oranges in mochitests (need ideas)

On Fri, Jul 7, 2017 at 12:15 PM, Ehsan Akhgari wrote: > FWIW years ago I decided to act on trying to detect some of the patterns > indicated on that page automatically, see https://bugzilla.mozilla.org/s > how_bug.cgi?id=649012. It didn't use linting (because we didn't really > have any linting

Re: Linting for common causes of oranges in mochitests (need ideas)

> > > On 7/6/17 11:47 AM, Andrew Halberstadt wrote: > > - Are there additional things not listed on that page that we could lint > for? > > > Do we want to discourage tests from using Date (`new Date` or > `Date.now()`) for measuring time? Dates are affected by time zon

Linting for common causes of oranges in mochitests (need ideas)

I'm looking into creating custom eslint rules that aim to avoid common causes of oranges in tests. We have an MDN page containing some of these already. Some of those patterns might be pretty hard to catch with a li

Re: Errors found by cppcheck

> checks that rare valuable ones to have turned on by default, and leave the > rest off by default. (I'm hoping the effectiveness of its check isn't > context sensitive...) > > > > On 06/06/2017 09:06 AM, Andrew Halberstadt wrote: > >> I was doing a bit o

Errors found by cppcheck

I was doing a bit of research into cppcheck [1] to see if it might be worth running as a linter (alongside eslint, flake8 etc). More discussion in bug 1370292 [2]. I ran it against the entire tree [3] and got these results: https://bug1370292.bmoattachments.org/attachment.cgi?id=8874498 So far it

Re: Sheriff Highlights and Summary in February 2017

I don't have any data to back this up, but my suspicion is that a large percentage of backouts had try runs, but said try runs didn't run the jobs that failed and caused the backout. Imo, these kinds of backouts are (more) acceptable because it means the developer was trying to avoid doing a full t

Re: Project Stockwell - February 2017 update

Just noticed no one looped back here. Joel filed bug 1337844 and bug 1337839 . There has been some discussion there. To summarize, running tests locally is currently optimized towards "Run a

Re: Several leak failures have slipped passed continuous integration

Ah, I misunderstood. If the log line is printed or dumped directly to stdout, then the string TEST-UNEXPECTED-FAIL actually will fail the job. It's only if we do log.info('TEST-UNEXPECTED-FAIL ...') that we run into problems. So if you see the string 'TEST-UNEXPECTED-FAIL' somewhere, it isn't nec

Several leak failures have slipped passed continuous integration

Over the holidays, we noticed that leaks in mochitest and reftest were not turning jobs orange, and that the test harnesses had been running in that state for quite some time. During this time several leak related test failures have landed, which can be tracked with this dependency tree: https:

Re: Rust required to build Gecko

When first installing rust with ./mach bootstrap the install is successful, but there is a message about not being able to find the compiler immediately afterwards. For anyone confused by this, the binaries are downloaded to ~/.cargo/bin and adding this directory to your $PATH should fix the issu

ESlint infrastructure moved to 'tools/lint'

If you had any absolute paths in editor configuration, you'll need to update them to point to 'tools/lint/eslint'. This change was in preparation for getting |mach eslint| integrated with the mozlint library, see bug 1258341 for details. My aim will be to maintain backwards compatibility both in

Re: Searchfox (new code search tool)

On 07/06/16 01:18 AM, Mike Hommey wrote: I'm going to sound negative, but why? Or more precisely, why not contribute to DXR to add those features that you implemented in searchfox that DXR doesn't have? MXR is already taking too long to fade out of existence, do we really want yet another differ

Re: One Firefox repository to rule them all

This is really cool! Though I much prefer firefoxtree's namespace updating to keep track of remote heads over using bookmarks. I want a label that will always point to the last known head on the server, so e.g `hg update central && hg commit -m "Foo"` should not move 'central'. Using bookmarks to

Mach command aliases and runtime configuration

Hey all, bug 1255450 has landed which means.. For mach users: You can now create a machrc (or .machrc) file in the following locations: * $MACHRC * ~/.mozbuild * topsrcdir In the future, individual commands may implement their own settings, but for now a single section called 'alias' is implemen

Re: Intent to enable e10s by default when running tests locally

. There is no eta at this time. -Andrew On 24/03/16 12:15 PM, Andrew Halberstadt wrote: Bug 1243083 tracks enabling e10s by default when running tests locally. I intend to do this for as many harnesses as possible unless someone says otherwise. The implication is that the --e10s flag will be

Re: Intent to enable e10s by default when running tests locally

he ergonomics around testing both to be quite a footgun - it's a manual process to run tests under both modes, and it's too easy to forget to run tests under the other mode. Would be handy to have a switch to enable running under both modes (or even better, defaulting to both modes). - Blai

Re: Intent to enable e10s by default when running tests locally

switch to enable running under both modes (or even better, defaulting to both modes). - Blair Andrew Halberstadt wrote: Bug 1243083 tracks enabling e10s by default when running tests locally. I intend to do this for as many harnesses as possible unless someone says otherwise. The implicatio

Re: Intent to enable e10s by default when running tests locally

sn't a big deal. On 24/03/16 01:25 PM, Andrew McCreight wrote: On Thu, Mar 24, 2016 at 9:15 AM, Andrew Halberstadt < ahalberst...@mozilla.com> wrote: Bug 1243083 tracks enabling e10s by default when running tests locally. I intend to do this for as many harnesses as possible unless s

Re: Intent to enable e10s by default when running tests locally

ll be able to make a .machrc with: [defaults] mochitest = --disable-e10s On 24/03/16 12:30 PM, Boris Zbarsky wrote: On 3/24/16 12:15 PM, Andrew Halberstadt wrote: If you have any concerns or know of other suites that should explicitly *not* be run with e10s enabled by default, please let me kno

Intent to enable e10s by default when running tests locally

Bug 1243083 tracks enabling e10s by default when running tests locally. I intend to do this for as many harnesses as possible unless someone says otherwise. The implication is that the --e10s flag will be renamed to --disable-e10s. So you'll need to pass in --disable-e10s if you wish to run witho

Re: Try syntax is no longer required when pushing to try

On 03/03/16 12:37 PM, Andreas Tolfsen wrote: On 3 March 2016 at 17:25, Andrew Halberstadt wrote: With treeherder's "Add New Jobs" [1] UI, using try syntax is no longer the only way to schedule stuff on try. As of now, it's possible to push to try without any try syntax. If

Try syntax is no longer required when pushing to try

With treeherder's "Add New Jobs" [1] UI, using try syntax is no longer the only way to schedule stuff on try. As of now, it's possible to push to try without any try syntax. If you do this, no jobs will be scheduled on your push and it will be up to you to add whichever jobs you want via "Add New

Re: firefox-ui-tests are now in mozilla-central with TaskCluster support

They're more like end-to-end tests than browser-chrome. E.g instead of calling Gecko APIs, they'll send a mouse event to a button, send key events to a textbox, etc. So they'll theoretically perform actions closer to what a user might do. Since they're written in python, they can also do things l

Re: Exit code -11 must die

On 29/02/16 12:03 PM, Benjamin Smedberg wrote: On 2/27/2016 9:06 PM, Randell Jesup wrote: months until recently it popped up a bit). Note that this failure *never* results in a crashdump, and I've never seen it locally, just in Automation. What we do know: * Exit code -11 is evidence a SIG

Test automation addons and signing

To date, our continuous integration has been setting 'xpinstall.signatures.required=false' to bypass addon signing. But soon, this pref will become obsolete and Firefox will enforce signing no matter what. In preparation, we will begin signing extensions that are used in our test automation. If y

Re: Generic Task Cluster Tasks / File Based Task Scheduling

On 17/02/16 01:59 PM, Gregory Szorc wrote: * You can now only run tasks if certain files changed. This opens the door for drastic reduction in automation load via more intelligent scheduling of tasks via in-tree configurations. (For the curious, relevant commits/files are determined from a combin

Re: Reftests moving to structured logging

This is now live on central. On 04/02/16 01:28 PM, Andrew Halberstadt wrote: Reftest is the last major test harness still not using structured logs, but that should change by the end of the week. See bug 1034290 [1] for more details. I've tried my best to make sure things like reftest-ana

Reftests moving to structured logging

Reftest is the last major test harness still not using structured logs, but that should change by the end of the week. See bug 1034290 [1] for more details. I've tried my best to make sure things like reftest-analyzer, leak/assertion checks, crash detection, etc. all continue to work. But due to

Re: Just Autoland It

On 28/01/16 06:31 PM, Eric Rescorla wrote: On Thu, Jan 28, 2016 at 10:58 AM, Gregory Szorc wrote: I'd like to thank everyone for the feedback in this thread. However, the thread has grown quite long and has detoured from its original subject. Speaking on behalf of everyone who works on MozRev

Re: Moving FirefoxOS into Tier 3 support

Hi, I'm on the engineering productivity team, and work a lot on continuous integration and test harnesses. I stood up initial Gecko unittests on B2G emulator, worked on B2G automation for several years up until the divide, and still help nominally maintain the emulator and mulet unittests. So that

Re: Just Autoland It

On 25/01/16 05:44 PM, Eric Rescorla wrote: On Mon, Jan 25, 2016 at 1:58 PM, Mike Hommey wrote: On Mon, Jan 25, 2016 at 11:23:59AM -0800, Steve Fink wrote: Heh. Your list of UI complaints is very similar to mine. Some comments: On 01/25/2016 04:26 AM, Honza Bambas wrote: Writing both as a p

Re: Moving FirefoxOS into Tier 3 support

On 25/01/16 11:00 AM, Fabrice Desré wrote: We're also working on a solution to move the b2g builds & tests to their own infrastructure from which we'll ship our builds & updates. What specifically does this mean? Do you mean infrastructure at the IT level? Or at the continuous integration le

Re: Just Autoland It

On 22/01/16 10:30 AM, Boris Zbarsky wrote: On 1/22/16 10:08 AM, Andrew Halberstadt wrote: In the end, it's on the reviewer. If the patch is complicated, has open dependencies or looks like it might cause problems, as a reviewer I'm not going to land it no matter what. If it's

Re: Just Autoland It

On 22/01/16 02:12 AM, Gregory Szorc wrote: On Thu, Jan 21, 2016 at 10:37 PM, Mike Connor wrote: Like Greg, I'm a big fan of reviewer-lands-if-ready. It's a huge simplification of workflow, saves developers time, and lets machines do work instead of humans. That said, I don't think we should be

Re: Just Autoland It

On 22/01/16 12:20 AM, Nicholas Nethercote wrote: On Thu, Jan 21, 2016 at 6:35 PM, Gregory Szorc wrote: I've gotten into the habit of just landing things if I r+ them and I think they are ready to land. This has startled a few people because it is a major role reversal of how we've done things

Re: ESLint checks are now running on the nightly trees on checkin

On 14/01/16 12:24 PM, Dave Townsend wrote: All hail the mighty releng folks who have made it so ridiculously easy to prototype and deploy new taskcluster tests! I just want to emphasize the significance here. A developer unaffiliated with either releng or the ateam and with only minimal support

  1   2   >