2017-05-16 16:34:58 +03:00
|
|
|
# -*- Mode: python; c-basic-offset: 4; indent-tabs-mode: nil; tab-width: 40 -*-
|
|
|
|
# vim: set filetype=python:
|
|
|
|
# This Source Code Form is subject to the terms of the Mozilla Public
|
|
|
|
# License, v. 2.0. If a copy of the MPL was not distributed with this
|
|
|
|
# file, You can obtain one at http://mozilla.org/MPL/2.0/.
|
|
|
|
|
|
|
|
import json
|
|
|
|
import os
|
|
|
|
import platform
|
|
|
|
import re
|
2019-09-11 22:52:08 +03:00
|
|
|
import shutil
|
2017-05-16 16:34:58 +03:00
|
|
|
import subprocess
|
|
|
|
import sys
|
2018-08-09 20:22:48 +03:00
|
|
|
import tempfile
|
2018-09-25 21:15:51 +03:00
|
|
|
from distutils.version import LooseVersion, StrictVersion
|
2019-09-11 22:52:08 +03:00
|
|
|
from filecmp import dircmp
|
|
|
|
|
2018-09-25 21:15:51 +03:00
|
|
|
from mozbuild.nodeutil import (find_node_executable, find_npm_executable,
|
|
|
|
NPM_MIN_VERSION, NODE_MIN_VERSION)
|
2019-09-11 22:52:08 +03:00
|
|
|
from mozbuild.util import ensure_subprocess_env
|
|
|
|
from mozfile.mozfile import remove as mozfileremove
|
|
|
|
|
2017-07-14 13:39:57 +03:00
|
|
|
|
2017-05-17 20:37:21 +03:00
|
|
|
NODE_MACHING_VERSION_NOT_FOUND_MESSAGE = """
|
2018-09-25 21:15:51 +03:00
|
|
|
Could not find Node.js executable later than %s.
|
|
|
|
|
|
|
|
Executing `mach bootstrap --no-system-changes` should
|
|
|
|
install a compatible version in ~/.mozbuild on most platforms.
|
2017-05-17 20:37:21 +03:00
|
|
|
""".strip()
|
|
|
|
|
2017-07-14 13:39:57 +03:00
|
|
|
NPM_MACHING_VERSION_NOT_FOUND_MESSAGE = """
|
2018-09-25 21:15:51 +03:00
|
|
|
Could not find npm executable later than %s.
|
2017-07-14 13:39:57 +03:00
|
|
|
|
2018-09-25 21:15:51 +03:00
|
|
|
Executing `mach bootstrap --no-system-changes` should
|
|
|
|
install a compatible version in ~/.mozbuild on most platforms.
|
2017-07-14 13:39:57 +03:00
|
|
|
""".strip()
|
|
|
|
|
2017-05-16 16:34:58 +03:00
|
|
|
NODE_NOT_FOUND_MESSAGE = """
|
2017-05-17 20:37:21 +03:00
|
|
|
nodejs is either not installed or is installed to a non-standard path.
|
2017-05-16 16:34:58 +03:00
|
|
|
|
2018-09-25 21:15:51 +03:00
|
|
|
Executing `mach bootstrap --no-system-changes` should
|
|
|
|
install a compatible version in ~/.mozbuild on most platforms.
|
2017-05-16 16:34:58 +03:00
|
|
|
""".strip()
|
|
|
|
|
|
|
|
NPM_NOT_FOUND_MESSAGE = """
|
|
|
|
Node Package Manager (npm) is either not installed or installed to a
|
2018-09-25 21:15:51 +03:00
|
|
|
non-standard path.
|
2017-05-16 16:34:58 +03:00
|
|
|
|
2018-09-25 21:15:51 +03:00
|
|
|
Executing `mach bootstrap --no-system-changes` should
|
|
|
|
install a compatible version in ~/.mozbuild on most platforms.
|
2017-05-16 16:34:58 +03:00
|
|
|
""".strip()
|
|
|
|
|
|
|
|
|
|
|
|
VERSION_RE = re.compile(r"^\d+\.\d+\.\d+$")
|
|
|
|
CARET_VERSION_RANGE_RE = re.compile(r"^\^((\d+)\.\d+\.\d+)$")
|
|
|
|
|
|
|
|
project_root = None
|
|
|
|
|
|
|
|
|
2017-11-07 17:30:56 +03:00
|
|
|
def eslint_maybe_setup():
|
|
|
|
"""Setup ESLint only if it is needed."""
|
|
|
|
has_issues, needs_clobber = eslint_module_needs_setup()
|
|
|
|
|
|
|
|
if has_issues:
|
|
|
|
eslint_setup(needs_clobber)
|
|
|
|
|
|
|
|
|
|
|
|
def eslint_setup(should_clobber=False):
|
2017-05-16 16:34:58 +03:00
|
|
|
"""Ensure eslint is optimally configured.
|
|
|
|
|
|
|
|
This command will inspect your eslint configuration and
|
|
|
|
guide you through an interactive wizard helping you configure
|
|
|
|
eslint for optimal use on Mozilla projects.
|
|
|
|
"""
|
Bug 1543247 - Part 1: Add `mach browsertime` command that installs and invokes browsertime. r=Standard8,ahal
[browsertime](https://github.com/sitespeedio/browsertime) is a harness
for running performance tests, similar to Mozilla's Raptor testing
framework. The Performance Team is using it locally with some
success, but we're running a heavily modified toolchain that is
challenging to install. This mach command is intended to be leverage
for getting more folks able to use browsertime easily.
In particular, the version of browsertime that this installs has
nalexander's changes to support testing GeckoView-based vehicles. If
this approach meets with approval, I'll continue to follow-up with
additional configuration and tooling layers to make it even easier to
drive GeckoView-based vehicles.
I elected to piggy-back install on the eslint installation process,
since this is very similar. To that end, I generalized what was there
very slightly. I elected not to try to move the existing code into a
more obvious shared location, although it might be possible, because
it wasn't clear what contexts the existing code would be invoked
from. In particular I wasn't certain the code could rely on a
complete mozbuild checkout.
I did need to ensure the local Node.js binary is early on the PATH;
this was an issue I ran into with my initial Node/Yarn prototyping
many months ago. At heart the issue is that package scripts in the
wild invoke a bare `node` or `npm` command; if there was a culture of
invoking $NODE or $NPM, this wouldn't be necessary. There's no harm
doing it for ESlint, and it will help the next person who wants to
install an NPM package for tooling in this manner.
Differential Revision: https://phabricator.services.mozilla.com/D26820
--HG--
extra : moz-landing-system : lando
2019-05-07 02:56:49 +03:00
|
|
|
package_setup(get_project_root(), 'eslint', should_clobber=should_clobber)
|
2017-05-16 16:34:58 +03:00
|
|
|
|
|
|
|
|
2019-07-24 23:58:39 +03:00
|
|
|
def package_setup(package_root, package_name, should_clobber=False, no_optional=False):
|
Bug 1543247 - Part 1: Add `mach browsertime` command that installs and invokes browsertime. r=Standard8,ahal
[browsertime](https://github.com/sitespeedio/browsertime) is a harness
for running performance tests, similar to Mozilla's Raptor testing
framework. The Performance Team is using it locally with some
success, but we're running a heavily modified toolchain that is
challenging to install. This mach command is intended to be leverage
for getting more folks able to use browsertime easily.
In particular, the version of browsertime that this installs has
nalexander's changes to support testing GeckoView-based vehicles. If
this approach meets with approval, I'll continue to follow-up with
additional configuration and tooling layers to make it even easier to
drive GeckoView-based vehicles.
I elected to piggy-back install on the eslint installation process,
since this is very similar. To that end, I generalized what was there
very slightly. I elected not to try to move the existing code into a
more obvious shared location, although it might be possible, because
it wasn't clear what contexts the existing code would be invoked
from. In particular I wasn't certain the code could rely on a
complete mozbuild checkout.
I did need to ensure the local Node.js binary is early on the PATH;
this was an issue I ran into with my initial Node/Yarn prototyping
many months ago. At heart the issue is that package scripts in the
wild invoke a bare `node` or `npm` command; if there was a culture of
invoking $NODE or $NPM, this wouldn't be necessary. There's no harm
doing it for ESlint, and it will help the next person who wants to
install an NPM package for tooling in this manner.
Differential Revision: https://phabricator.services.mozilla.com/D26820
--HG--
extra : moz-landing-system : lando
2019-05-07 02:56:49 +03:00
|
|
|
"""Ensure `package_name` at `package_root` is installed.
|
2018-11-27 17:46:53 +03:00
|
|
|
|
Bug 1543247 - Part 1: Add `mach browsertime` command that installs and invokes browsertime. r=Standard8,ahal
[browsertime](https://github.com/sitespeedio/browsertime) is a harness
for running performance tests, similar to Mozilla's Raptor testing
framework. The Performance Team is using it locally with some
success, but we're running a heavily modified toolchain that is
challenging to install. This mach command is intended to be leverage
for getting more folks able to use browsertime easily.
In particular, the version of browsertime that this installs has
nalexander's changes to support testing GeckoView-based vehicles. If
this approach meets with approval, I'll continue to follow-up with
additional configuration and tooling layers to make it even easier to
drive GeckoView-based vehicles.
I elected to piggy-back install on the eslint installation process,
since this is very similar. To that end, I generalized what was there
very slightly. I elected not to try to move the existing code into a
more obvious shared location, although it might be possible, because
it wasn't clear what contexts the existing code would be invoked
from. In particular I wasn't certain the code could rely on a
complete mozbuild checkout.
I did need to ensure the local Node.js binary is early on the PATH;
this was an issue I ran into with my initial Node/Yarn prototyping
many months ago. At heart the issue is that package scripts in the
wild invoke a bare `node` or `npm` command; if there was a culture of
invoking $NODE or $NPM, this wouldn't be necessary. There's no harm
doing it for ESlint, and it will help the next person who wants to
install an NPM package for tooling in this manner.
Differential Revision: https://phabricator.services.mozilla.com/D26820
--HG--
extra : moz-landing-system : lando
2019-05-07 02:56:49 +03:00
|
|
|
This populates `package_root/node_modules`.
|
|
|
|
"""
|
|
|
|
orig_project_root = get_project_root()
|
|
|
|
orig_cwd = os.getcwd()
|
|
|
|
try:
|
|
|
|
set_project_root(package_root)
|
|
|
|
sys.path.append(os.path.dirname(__file__))
|
|
|
|
|
|
|
|
# npm sometimes fails to respect cwd when it is run using check_call so
|
|
|
|
# we manually switch folders here instead.
|
|
|
|
project_root = get_project_root()
|
|
|
|
os.chdir(project_root)
|
|
|
|
|
|
|
|
if should_clobber:
|
|
|
|
node_modules_path = os.path.join(project_root, "node_modules")
|
|
|
|
print("Clobbering %s..." % node_modules_path)
|
|
|
|
if sys.platform.startswith('win') and have_winrm():
|
|
|
|
process = subprocess.Popen(['winrm', '-rf', node_modules_path])
|
|
|
|
process.wait()
|
|
|
|
else:
|
|
|
|
mozfileremove(node_modules_path)
|
|
|
|
|
|
|
|
npm_path, version = find_npm_executable()
|
|
|
|
if not npm_path:
|
|
|
|
return 1
|
|
|
|
|
|
|
|
node_path, _ = find_node_executable()
|
|
|
|
if not node_path:
|
|
|
|
return 1
|
|
|
|
|
|
|
|
extra_parameters = ["--loglevel=error"]
|
|
|
|
|
2019-07-24 23:58:39 +03:00
|
|
|
if no_optional:
|
|
|
|
extra_parameters.append('--no-optional')
|
|
|
|
|
Bug 1543247 - Part 1: Add `mach browsertime` command that installs and invokes browsertime. r=Standard8,ahal
[browsertime](https://github.com/sitespeedio/browsertime) is a harness
for running performance tests, similar to Mozilla's Raptor testing
framework. The Performance Team is using it locally with some
success, but we're running a heavily modified toolchain that is
challenging to install. This mach command is intended to be leverage
for getting more folks able to use browsertime easily.
In particular, the version of browsertime that this installs has
nalexander's changes to support testing GeckoView-based vehicles. If
this approach meets with approval, I'll continue to follow-up with
additional configuration and tooling layers to make it even easier to
drive GeckoView-based vehicles.
I elected to piggy-back install on the eslint installation process,
since this is very similar. To that end, I generalized what was there
very slightly. I elected not to try to move the existing code into a
more obvious shared location, although it might be possible, because
it wasn't clear what contexts the existing code would be invoked
from. In particular I wasn't certain the code could rely on a
complete mozbuild checkout.
I did need to ensure the local Node.js binary is early on the PATH;
this was an issue I ran into with my initial Node/Yarn prototyping
many months ago. At heart the issue is that package scripts in the
wild invoke a bare `node` or `npm` command; if there was a culture of
invoking $NODE or $NPM, this wouldn't be necessary. There's no harm
doing it for ESlint, and it will help the next person who wants to
install an NPM package for tooling in this manner.
Differential Revision: https://phabricator.services.mozilla.com/D26820
--HG--
extra : moz-landing-system : lando
2019-05-07 02:56:49 +03:00
|
|
|
package_lock_json_path = os.path.join(get_project_root(), "package-lock.json")
|
|
|
|
package_lock_json_tmp_path = os.path.join(tempfile.gettempdir(), "package-lock.json.tmp")
|
|
|
|
|
|
|
|
# If we have an npm version newer than 5.8.0, just use 'ci', as that's much
|
|
|
|
# simpler and does exactly what we want.
|
|
|
|
npm_is_older_version = version < StrictVersion("5.8.0").version
|
|
|
|
|
|
|
|
if npm_is_older_version:
|
|
|
|
cmd = [npm_path, "install"]
|
|
|
|
shutil.copy2(package_lock_json_path, package_lock_json_tmp_path)
|
|
|
|
else:
|
|
|
|
cmd = [npm_path, "ci"]
|
2017-05-16 16:34:58 +03:00
|
|
|
|
Bug 1543247 - Part 1: Add `mach browsertime` command that installs and invokes browsertime. r=Standard8,ahal
[browsertime](https://github.com/sitespeedio/browsertime) is a harness
for running performance tests, similar to Mozilla's Raptor testing
framework. The Performance Team is using it locally with some
success, but we're running a heavily modified toolchain that is
challenging to install. This mach command is intended to be leverage
for getting more folks able to use browsertime easily.
In particular, the version of browsertime that this installs has
nalexander's changes to support testing GeckoView-based vehicles. If
this approach meets with approval, I'll continue to follow-up with
additional configuration and tooling layers to make it even easier to
drive GeckoView-based vehicles.
I elected to piggy-back install on the eslint installation process,
since this is very similar. To that end, I generalized what was there
very slightly. I elected not to try to move the existing code into a
more obvious shared location, although it might be possible, because
it wasn't clear what contexts the existing code would be invoked
from. In particular I wasn't certain the code could rely on a
complete mozbuild checkout.
I did need to ensure the local Node.js binary is early on the PATH;
this was an issue I ran into with my initial Node/Yarn prototyping
many months ago. At heart the issue is that package scripts in the
wild invoke a bare `node` or `npm` command; if there was a culture of
invoking $NODE or $NPM, this wouldn't be necessary. There's no harm
doing it for ESlint, and it will help the next person who wants to
install an NPM package for tooling in this manner.
Differential Revision: https://phabricator.services.mozilla.com/D26820
--HG--
extra : moz-landing-system : lando
2019-05-07 02:56:49 +03:00
|
|
|
# On non-Windows, ensure npm is called via node, as node may not be in the
|
|
|
|
# path.
|
|
|
|
if platform.system() != "Windows":
|
|
|
|
cmd.insert(0, node_path)
|
2018-08-09 20:22:48 +03:00
|
|
|
|
Bug 1543247 - Part 1: Add `mach browsertime` command that installs and invokes browsertime. r=Standard8,ahal
[browsertime](https://github.com/sitespeedio/browsertime) is a harness
for running performance tests, similar to Mozilla's Raptor testing
framework. The Performance Team is using it locally with some
success, but we're running a heavily modified toolchain that is
challenging to install. This mach command is intended to be leverage
for getting more folks able to use browsertime easily.
In particular, the version of browsertime that this installs has
nalexander's changes to support testing GeckoView-based vehicles. If
this approach meets with approval, I'll continue to follow-up with
additional configuration and tooling layers to make it even easier to
drive GeckoView-based vehicles.
I elected to piggy-back install on the eslint installation process,
since this is very similar. To that end, I generalized what was there
very slightly. I elected not to try to move the existing code into a
more obvious shared location, although it might be possible, because
it wasn't clear what contexts the existing code would be invoked
from. In particular I wasn't certain the code could rely on a
complete mozbuild checkout.
I did need to ensure the local Node.js binary is early on the PATH;
this was an issue I ran into with my initial Node/Yarn prototyping
many months ago. At heart the issue is that package scripts in the
wild invoke a bare `node` or `npm` command; if there was a culture of
invoking $NODE or $NPM, this wouldn't be necessary. There's no harm
doing it for ESlint, and it will help the next person who wants to
install an NPM package for tooling in this manner.
Differential Revision: https://phabricator.services.mozilla.com/D26820
--HG--
extra : moz-landing-system : lando
2019-05-07 02:56:49 +03:00
|
|
|
cmd.extend(extra_parameters)
|
2018-08-09 20:22:48 +03:00
|
|
|
|
Bug 1543247 - Part 1: Add `mach browsertime` command that installs and invokes browsertime. r=Standard8,ahal
[browsertime](https://github.com/sitespeedio/browsertime) is a harness
for running performance tests, similar to Mozilla's Raptor testing
framework. The Performance Team is using it locally with some
success, but we're running a heavily modified toolchain that is
challenging to install. This mach command is intended to be leverage
for getting more folks able to use browsertime easily.
In particular, the version of browsertime that this installs has
nalexander's changes to support testing GeckoView-based vehicles. If
this approach meets with approval, I'll continue to follow-up with
additional configuration and tooling layers to make it even easier to
drive GeckoView-based vehicles.
I elected to piggy-back install on the eslint installation process,
since this is very similar. To that end, I generalized what was there
very slightly. I elected not to try to move the existing code into a
more obvious shared location, although it might be possible, because
it wasn't clear what contexts the existing code would be invoked
from. In particular I wasn't certain the code could rely on a
complete mozbuild checkout.
I did need to ensure the local Node.js binary is early on the PATH;
this was an issue I ran into with my initial Node/Yarn prototyping
many months ago. At heart the issue is that package scripts in the
wild invoke a bare `node` or `npm` command; if there was a culture of
invoking $NODE or $NPM, this wouldn't be necessary. There's no harm
doing it for ESlint, and it will help the next person who wants to
install an NPM package for tooling in this manner.
Differential Revision: https://phabricator.services.mozilla.com/D26820
--HG--
extra : moz-landing-system : lando
2019-05-07 02:56:49 +03:00
|
|
|
# Ensure that bare `node` and `npm` in scripts, including post-install scripts, finds the
|
|
|
|
# binary we're invoking with. Without this, it's easy for compiled extensions to get
|
|
|
|
# mismatched versions of the Node.js extension API.
|
|
|
|
path = os.environ.get('PATH', '').split(os.pathsep)
|
|
|
|
node_dir = os.path.dirname(node_path)
|
|
|
|
if node_dir not in path:
|
|
|
|
path = [node_dir] + path
|
2018-11-30 00:41:13 +03:00
|
|
|
|
Bug 1543247 - Part 1: Add `mach browsertime` command that installs and invokes browsertime. r=Standard8,ahal
[browsertime](https://github.com/sitespeedio/browsertime) is a harness
for running performance tests, similar to Mozilla's Raptor testing
framework. The Performance Team is using it locally with some
success, but we're running a heavily modified toolchain that is
challenging to install. This mach command is intended to be leverage
for getting more folks able to use browsertime easily.
In particular, the version of browsertime that this installs has
nalexander's changes to support testing GeckoView-based vehicles. If
this approach meets with approval, I'll continue to follow-up with
additional configuration and tooling layers to make it even easier to
drive GeckoView-based vehicles.
I elected to piggy-back install on the eslint installation process,
since this is very similar. To that end, I generalized what was there
very slightly. I elected not to try to move the existing code into a
more obvious shared location, although it might be possible, because
it wasn't clear what contexts the existing code would be invoked
from. In particular I wasn't certain the code could rely on a
complete mozbuild checkout.
I did need to ensure the local Node.js binary is early on the PATH;
this was an issue I ran into with my initial Node/Yarn prototyping
many months ago. At heart the issue is that package scripts in the
wild invoke a bare `node` or `npm` command; if there was a culture of
invoking $NODE or $NPM, this wouldn't be necessary. There's no harm
doing it for ESlint, and it will help the next person who wants to
install an NPM package for tooling in this manner.
Differential Revision: https://phabricator.services.mozilla.com/D26820
--HG--
extra : moz-landing-system : lando
2019-05-07 02:56:49 +03:00
|
|
|
print("Installing %s for mach using \"%s\"..." % (package_name, " ".join(cmd)))
|
|
|
|
result = call_process(package_name, cmd, append_env={'PATH': os.pathsep.join(path)})
|
2018-08-09 20:22:48 +03:00
|
|
|
|
Bug 1543247 - Part 1: Add `mach browsertime` command that installs and invokes browsertime. r=Standard8,ahal
[browsertime](https://github.com/sitespeedio/browsertime) is a harness
for running performance tests, similar to Mozilla's Raptor testing
framework. The Performance Team is using it locally with some
success, but we're running a heavily modified toolchain that is
challenging to install. This mach command is intended to be leverage
for getting more folks able to use browsertime easily.
In particular, the version of browsertime that this installs has
nalexander's changes to support testing GeckoView-based vehicles. If
this approach meets with approval, I'll continue to follow-up with
additional configuration and tooling layers to make it even easier to
drive GeckoView-based vehicles.
I elected to piggy-back install on the eslint installation process,
since this is very similar. To that end, I generalized what was there
very slightly. I elected not to try to move the existing code into a
more obvious shared location, although it might be possible, because
it wasn't clear what contexts the existing code would be invoked
from. In particular I wasn't certain the code could rely on a
complete mozbuild checkout.
I did need to ensure the local Node.js binary is early on the PATH;
this was an issue I ran into with my initial Node/Yarn prototyping
many months ago. At heart the issue is that package scripts in the
wild invoke a bare `node` or `npm` command; if there was a culture of
invoking $NODE or $NPM, this wouldn't be necessary. There's no harm
doing it for ESlint, and it will help the next person who wants to
install an NPM package for tooling in this manner.
Differential Revision: https://phabricator.services.mozilla.com/D26820
--HG--
extra : moz-landing-system : lando
2019-05-07 02:56:49 +03:00
|
|
|
if npm_is_older_version:
|
|
|
|
shutil.move(package_lock_json_tmp_path, package_lock_json_path)
|
2018-08-09 20:22:48 +03:00
|
|
|
|
Bug 1543247 - Part 1: Add `mach browsertime` command that installs and invokes browsertime. r=Standard8,ahal
[browsertime](https://github.com/sitespeedio/browsertime) is a harness
for running performance tests, similar to Mozilla's Raptor testing
framework. The Performance Team is using it locally with some
success, but we're running a heavily modified toolchain that is
challenging to install. This mach command is intended to be leverage
for getting more folks able to use browsertime easily.
In particular, the version of browsertime that this installs has
nalexander's changes to support testing GeckoView-based vehicles. If
this approach meets with approval, I'll continue to follow-up with
additional configuration and tooling layers to make it even easier to
drive GeckoView-based vehicles.
I elected to piggy-back install on the eslint installation process,
since this is very similar. To that end, I generalized what was there
very slightly. I elected not to try to move the existing code into a
more obvious shared location, although it might be possible, because
it wasn't clear what contexts the existing code would be invoked
from. In particular I wasn't certain the code could rely on a
complete mozbuild checkout.
I did need to ensure the local Node.js binary is early on the PATH;
this was an issue I ran into with my initial Node/Yarn prototyping
many months ago. At heart the issue is that package scripts in the
wild invoke a bare `node` or `npm` command; if there was a culture of
invoking $NODE or $NPM, this wouldn't be necessary. There's no harm
doing it for ESlint, and it will help the next person who wants to
install an NPM package for tooling in this manner.
Differential Revision: https://phabricator.services.mozilla.com/D26820
--HG--
extra : moz-landing-system : lando
2019-05-07 02:56:49 +03:00
|
|
|
if not result:
|
|
|
|
return 1
|
2018-08-09 20:22:48 +03:00
|
|
|
|
Bug 1543247 - Part 1: Add `mach browsertime` command that installs and invokes browsertime. r=Standard8,ahal
[browsertime](https://github.com/sitespeedio/browsertime) is a harness
for running performance tests, similar to Mozilla's Raptor testing
framework. The Performance Team is using it locally with some
success, but we're running a heavily modified toolchain that is
challenging to install. This mach command is intended to be leverage
for getting more folks able to use browsertime easily.
In particular, the version of browsertime that this installs has
nalexander's changes to support testing GeckoView-based vehicles. If
this approach meets with approval, I'll continue to follow-up with
additional configuration and tooling layers to make it even easier to
drive GeckoView-based vehicles.
I elected to piggy-back install on the eslint installation process,
since this is very similar. To that end, I generalized what was there
very slightly. I elected not to try to move the existing code into a
more obvious shared location, although it might be possible, because
it wasn't clear what contexts the existing code would be invoked
from. In particular I wasn't certain the code could rely on a
complete mozbuild checkout.
I did need to ensure the local Node.js binary is early on the PATH;
this was an issue I ran into with my initial Node/Yarn prototyping
many months ago. At heart the issue is that package scripts in the
wild invoke a bare `node` or `npm` command; if there was a culture of
invoking $NODE or $NPM, this wouldn't be necessary. There's no harm
doing it for ESlint, and it will help the next person who wants to
install an NPM package for tooling in this manner.
Differential Revision: https://phabricator.services.mozilla.com/D26820
--HG--
extra : moz-landing-system : lando
2019-05-07 02:56:49 +03:00
|
|
|
bin_path = os.path.join(get_project_root(), "node_modules", ".bin", package_name)
|
2017-05-16 16:34:58 +03:00
|
|
|
|
Bug 1543247 - Part 1: Add `mach browsertime` command that installs and invokes browsertime. r=Standard8,ahal
[browsertime](https://github.com/sitespeedio/browsertime) is a harness
for running performance tests, similar to Mozilla's Raptor testing
framework. The Performance Team is using it locally with some
success, but we're running a heavily modified toolchain that is
challenging to install. This mach command is intended to be leverage
for getting more folks able to use browsertime easily.
In particular, the version of browsertime that this installs has
nalexander's changes to support testing GeckoView-based vehicles. If
this approach meets with approval, I'll continue to follow-up with
additional configuration and tooling layers to make it even easier to
drive GeckoView-based vehicles.
I elected to piggy-back install on the eslint installation process,
since this is very similar. To that end, I generalized what was there
very slightly. I elected not to try to move the existing code into a
more obvious shared location, although it might be possible, because
it wasn't clear what contexts the existing code would be invoked
from. In particular I wasn't certain the code could rely on a
complete mozbuild checkout.
I did need to ensure the local Node.js binary is early on the PATH;
this was an issue I ran into with my initial Node/Yarn prototyping
many months ago. At heart the issue is that package scripts in the
wild invoke a bare `node` or `npm` command; if there was a culture of
invoking $NODE or $NPM, this wouldn't be necessary. There's no harm
doing it for ESlint, and it will help the next person who wants to
install an NPM package for tooling in this manner.
Differential Revision: https://phabricator.services.mozilla.com/D26820
--HG--
extra : moz-landing-system : lando
2019-05-07 02:56:49 +03:00
|
|
|
print("\n%s installed successfully!" % package_name)
|
|
|
|
print("\nNOTE: Your local %s binary is at %s\n" % (package_name, bin_path))
|
2017-05-16 16:34:58 +03:00
|
|
|
|
Bug 1543247 - Part 1: Add `mach browsertime` command that installs and invokes browsertime. r=Standard8,ahal
[browsertime](https://github.com/sitespeedio/browsertime) is a harness
for running performance tests, similar to Mozilla's Raptor testing
framework. The Performance Team is using it locally with some
success, but we're running a heavily modified toolchain that is
challenging to install. This mach command is intended to be leverage
for getting more folks able to use browsertime easily.
In particular, the version of browsertime that this installs has
nalexander's changes to support testing GeckoView-based vehicles. If
this approach meets with approval, I'll continue to follow-up with
additional configuration and tooling layers to make it even easier to
drive GeckoView-based vehicles.
I elected to piggy-back install on the eslint installation process,
since this is very similar. To that end, I generalized what was there
very slightly. I elected not to try to move the existing code into a
more obvious shared location, although it might be possible, because
it wasn't clear what contexts the existing code would be invoked
from. In particular I wasn't certain the code could rely on a
complete mozbuild checkout.
I did need to ensure the local Node.js binary is early on the PATH;
this was an issue I ran into with my initial Node/Yarn prototyping
many months ago. At heart the issue is that package scripts in the
wild invoke a bare `node` or `npm` command; if there was a culture of
invoking $NODE or $NPM, this wouldn't be necessary. There's no harm
doing it for ESlint, and it will help the next person who wants to
install an NPM package for tooling in this manner.
Differential Revision: https://phabricator.services.mozilla.com/D26820
--HG--
extra : moz-landing-system : lando
2019-05-07 02:56:49 +03:00
|
|
|
finally:
|
|
|
|
set_project_root(orig_project_root)
|
|
|
|
os.chdir(orig_cwd)
|
2017-05-16 16:34:58 +03:00
|
|
|
|
|
|
|
|
Bug 1543247 - Part 1: Add `mach browsertime` command that installs and invokes browsertime. r=Standard8,ahal
[browsertime](https://github.com/sitespeedio/browsertime) is a harness
for running performance tests, similar to Mozilla's Raptor testing
framework. The Performance Team is using it locally with some
success, but we're running a heavily modified toolchain that is
challenging to install. This mach command is intended to be leverage
for getting more folks able to use browsertime easily.
In particular, the version of browsertime that this installs has
nalexander's changes to support testing GeckoView-based vehicles. If
this approach meets with approval, I'll continue to follow-up with
additional configuration and tooling layers to make it even easier to
drive GeckoView-based vehicles.
I elected to piggy-back install on the eslint installation process,
since this is very similar. To that end, I generalized what was there
very slightly. I elected not to try to move the existing code into a
more obvious shared location, although it might be possible, because
it wasn't clear what contexts the existing code would be invoked
from. In particular I wasn't certain the code could rely on a
complete mozbuild checkout.
I did need to ensure the local Node.js binary is early on the PATH;
this was an issue I ran into with my initial Node/Yarn prototyping
many months ago. At heart the issue is that package scripts in the
wild invoke a bare `node` or `npm` command; if there was a culture of
invoking $NODE or $NPM, this wouldn't be necessary. There's no harm
doing it for ESlint, and it will help the next person who wants to
install an NPM package for tooling in this manner.
Differential Revision: https://phabricator.services.mozilla.com/D26820
--HG--
extra : moz-landing-system : lando
2019-05-07 02:56:49 +03:00
|
|
|
def call_process(name, cmd, cwd=None, append_env={}):
|
|
|
|
env = dict(os.environ)
|
2019-09-05 02:50:26 +03:00
|
|
|
env.update(ensure_subprocess_env(append_env))
|
2017-05-16 16:34:58 +03:00
|
|
|
|
|
|
|
try:
|
|
|
|
with open(os.devnull, "w") as fnull:
|
Bug 1543247 - Part 1: Add `mach browsertime` command that installs and invokes browsertime. r=Standard8,ahal
[browsertime](https://github.com/sitespeedio/browsertime) is a harness
for running performance tests, similar to Mozilla's Raptor testing
framework. The Performance Team is using it locally with some
success, but we're running a heavily modified toolchain that is
challenging to install. This mach command is intended to be leverage
for getting more folks able to use browsertime easily.
In particular, the version of browsertime that this installs has
nalexander's changes to support testing GeckoView-based vehicles. If
this approach meets with approval, I'll continue to follow-up with
additional configuration and tooling layers to make it even easier to
drive GeckoView-based vehicles.
I elected to piggy-back install on the eslint installation process,
since this is very similar. To that end, I generalized what was there
very slightly. I elected not to try to move the existing code into a
more obvious shared location, although it might be possible, because
it wasn't clear what contexts the existing code would be invoked
from. In particular I wasn't certain the code could rely on a
complete mozbuild checkout.
I did need to ensure the local Node.js binary is early on the PATH;
this was an issue I ran into with my initial Node/Yarn prototyping
many months ago. At heart the issue is that package scripts in the
wild invoke a bare `node` or `npm` command; if there was a culture of
invoking $NODE or $NPM, this wouldn't be necessary. There's no harm
doing it for ESlint, and it will help the next person who wants to
install an NPM package for tooling in this manner.
Differential Revision: https://phabricator.services.mozilla.com/D26820
--HG--
extra : moz-landing-system : lando
2019-05-07 02:56:49 +03:00
|
|
|
subprocess.check_call(cmd, cwd=cwd, stdout=fnull, env=env)
|
2017-05-16 16:34:58 +03:00
|
|
|
except subprocess.CalledProcessError:
|
|
|
|
if cwd:
|
|
|
|
print("\nError installing %s in the %s folder, aborting." % (name, cwd))
|
|
|
|
else:
|
|
|
|
print("\nError installing %s, aborting." % name)
|
|
|
|
|
|
|
|
return False
|
|
|
|
|
|
|
|
return True
|
|
|
|
|
|
|
|
|
|
|
|
def expected_eslint_modules():
|
|
|
|
# Read the expected version of ESLint and external modules
|
|
|
|
expected_modules_path = os.path.join(get_project_root(), "package.json")
|
2019-10-02 16:07:37 +03:00
|
|
|
with open(expected_modules_path, "r", encoding="utf-8") as f:
|
2019-05-15 17:34:09 +03:00
|
|
|
sections = json.load(f)
|
|
|
|
expected_modules = sections["dependencies"]
|
|
|
|
expected_modules.update(sections["devDependencies"])
|
2017-05-16 16:34:58 +03:00
|
|
|
|
2017-07-14 13:55:37 +03:00
|
|
|
# Also read the in-tree ESLint plugin mozilla information, to ensure the
|
|
|
|
# dependencies are up to date.
|
2017-05-16 16:34:58 +03:00
|
|
|
mozilla_json_path = os.path.join(get_eslint_module_path(),
|
|
|
|
"eslint-plugin-mozilla", "package.json")
|
2019-10-02 16:07:37 +03:00
|
|
|
with open(mozilla_json_path, "r", encoding="utf-8") as f:
|
2017-07-14 13:55:37 +03:00
|
|
|
expected_modules.update(json.load(f)["dependencies"])
|
2017-05-16 16:34:58 +03:00
|
|
|
|
2017-07-14 13:55:37 +03:00
|
|
|
# Also read the in-tree ESLint plugin spidermonkey information, to ensure the
|
|
|
|
# dependencies are up to date.
|
2017-05-16 16:34:58 +03:00
|
|
|
mozilla_json_path = os.path.join(get_eslint_module_path(),
|
|
|
|
"eslint-plugin-spidermonkey-js", "package.json")
|
2019-10-02 16:07:37 +03:00
|
|
|
with open(mozilla_json_path, "r", encoding="utf-8") as f:
|
2017-07-14 13:55:37 +03:00
|
|
|
expected_modules.update(json.load(f)["dependencies"])
|
2017-05-16 16:34:58 +03:00
|
|
|
|
|
|
|
return expected_modules
|
|
|
|
|
|
|
|
|
|
|
|
def check_eslint_files(node_modules_path, name):
|
|
|
|
def check_file_diffs(dcmp):
|
|
|
|
# Diff files only looks at files that are different. Not for files
|
|
|
|
# that are only present on one side. This should be generally OK as
|
|
|
|
# new files will need to be added in the index.js for the package.
|
|
|
|
if dcmp.diff_files and dcmp.diff_files != ['package.json']:
|
|
|
|
return True
|
|
|
|
|
|
|
|
result = False
|
|
|
|
|
|
|
|
# Again, we only look at common sub directories for the same reason
|
|
|
|
# as above.
|
|
|
|
for sub_dcmp in dcmp.subdirs.values():
|
|
|
|
result = result or check_file_diffs(sub_dcmp)
|
|
|
|
|
|
|
|
return result
|
|
|
|
|
|
|
|
dcmp = dircmp(os.path.join(node_modules_path, name),
|
|
|
|
os.path.join(get_eslint_module_path(), name))
|
|
|
|
|
|
|
|
return check_file_diffs(dcmp)
|
|
|
|
|
|
|
|
|
|
|
|
def eslint_module_needs_setup():
|
|
|
|
has_issues = False
|
2017-11-07 17:30:56 +03:00
|
|
|
needs_clobber = False
|
2017-05-16 16:34:58 +03:00
|
|
|
node_modules_path = os.path.join(get_project_root(), "node_modules")
|
|
|
|
|
2019-09-11 22:52:08 +03:00
|
|
|
for name, expected_data in expected_eslint_modules().items():
|
2017-05-16 16:34:58 +03:00
|
|
|
# expected_eslint_modules returns a string for the version number of
|
|
|
|
# dependencies for installation of eslint generally, and an object
|
|
|
|
# for our in-tree plugins (which contains the entire module info).
|
|
|
|
if "version" in expected_data:
|
|
|
|
version_range = expected_data["version"]
|
|
|
|
else:
|
|
|
|
version_range = expected_data
|
|
|
|
|
|
|
|
path = os.path.join(node_modules_path, name, "package.json")
|
|
|
|
|
|
|
|
if not os.path.exists(path):
|
|
|
|
print("%s v%s needs to be installed locally." % (name, version_range))
|
|
|
|
has_issues = True
|
|
|
|
continue
|
2019-10-02 16:07:37 +03:00
|
|
|
data = json.load(open(path, encoding="utf-8"))
|
2017-05-16 16:34:58 +03:00
|
|
|
|
2017-07-14 13:55:37 +03:00
|
|
|
if version_range.startswith("file:"):
|
|
|
|
# We don't need to check local file installations for versions, as
|
|
|
|
# these are symlinked, so we'll always pick up the latest.
|
|
|
|
continue
|
|
|
|
|
2017-11-07 17:30:56 +03:00
|
|
|
if name == "eslint" and LooseVersion("4.0.0") > LooseVersion(data["version"]):
|
|
|
|
print("ESLint is an old version, clobbering node_modules directory")
|
|
|
|
needs_clobber = True
|
|
|
|
has_issues = True
|
|
|
|
continue
|
|
|
|
|
2017-05-16 16:34:58 +03:00
|
|
|
if not version_in_range(data["version"], version_range):
|
|
|
|
print("%s v%s should be v%s." % (name, data["version"], version_range))
|
|
|
|
has_issues = True
|
|
|
|
continue
|
|
|
|
|
2017-11-07 17:30:56 +03:00
|
|
|
return has_issues, needs_clobber
|
2017-05-16 16:34:58 +03:00
|
|
|
|
|
|
|
|
|
|
|
def version_in_range(version, version_range):
|
|
|
|
"""
|
|
|
|
Check if a module version is inside a version range. Only supports explicit versions and
|
|
|
|
caret ranges for the moment, since that's all we've used so far.
|
|
|
|
"""
|
|
|
|
if version == version_range:
|
|
|
|
return True
|
|
|
|
|
|
|
|
version_match = VERSION_RE.match(version)
|
|
|
|
if not version_match:
|
|
|
|
raise RuntimeError("mach eslint doesn't understand module version %s" % version)
|
|
|
|
version = LooseVersion(version)
|
|
|
|
|
|
|
|
# Caret ranges as specified by npm allow changes that do not modify the left-most non-zero
|
|
|
|
# digit in the [major, minor, patch] tuple. The code below assumes the major digit is
|
|
|
|
# non-zero.
|
|
|
|
range_match = CARET_VERSION_RANGE_RE.match(version_range)
|
|
|
|
if range_match:
|
|
|
|
range_version = range_match.group(1)
|
|
|
|
range_major = int(range_match.group(2))
|
|
|
|
|
|
|
|
range_min = LooseVersion(range_version)
|
|
|
|
range_max = LooseVersion("%d.0.0" % (range_major + 1))
|
|
|
|
|
|
|
|
return range_min <= version < range_max
|
|
|
|
|
|
|
|
return False
|
|
|
|
|
|
|
|
|
|
|
|
def get_possible_node_paths_win():
|
|
|
|
"""
|
|
|
|
Return possible nodejs paths on Windows.
|
|
|
|
"""
|
|
|
|
if platform.system() != "Windows":
|
|
|
|
return []
|
|
|
|
|
|
|
|
return list({
|
|
|
|
"%s\\nodejs" % os.environ.get("SystemDrive"),
|
|
|
|
os.path.join(os.environ.get("ProgramFiles"), "nodejs"),
|
|
|
|
os.path.join(os.environ.get("PROGRAMW6432"), "nodejs"),
|
|
|
|
os.path.join(os.environ.get("PROGRAMFILES"), "nodejs")
|
|
|
|
})
|
|
|
|
|
|
|
|
|
2017-05-17 20:37:21 +03:00
|
|
|
def get_version(path):
|
2017-05-16 16:34:58 +03:00
|
|
|
try:
|
2019-09-11 22:52:08 +03:00
|
|
|
version_str = subprocess.check_output([path, "--version"], stderr=subprocess.STDOUT,
|
|
|
|
universal_newlines=True)
|
2017-05-17 20:37:21 +03:00
|
|
|
return version_str
|
2017-05-16 16:34:58 +03:00
|
|
|
except (subprocess.CalledProcessError, OSError):
|
2017-05-17 20:37:21 +03:00
|
|
|
return None
|
2017-05-16 16:34:58 +03:00
|
|
|
|
|
|
|
|
|
|
|
def set_project_root(root=None):
|
|
|
|
"""Sets the project root to the supplied path, or works out what the root
|
|
|
|
is based on looking for 'mach'.
|
|
|
|
|
|
|
|
Keyword arguments:
|
|
|
|
root - (optional) The path to set the root to.
|
|
|
|
"""
|
|
|
|
global project_root
|
|
|
|
|
|
|
|
if root:
|
|
|
|
project_root = root
|
|
|
|
return
|
|
|
|
|
|
|
|
file_found = False
|
|
|
|
folder = os.getcwd()
|
|
|
|
|
|
|
|
while (folder):
|
|
|
|
if os.path.exists(os.path.join(folder, 'mach')):
|
|
|
|
file_found = True
|
|
|
|
break
|
|
|
|
else:
|
|
|
|
folder = os.path.dirname(folder)
|
|
|
|
|
|
|
|
if file_found:
|
|
|
|
project_root = os.path.abspath(folder)
|
|
|
|
|
|
|
|
|
|
|
|
def get_project_root():
|
|
|
|
"""Returns the absolute path to the root of the project, see set_project_root()
|
|
|
|
for how this is determined.
|
|
|
|
"""
|
|
|
|
global project_root
|
|
|
|
|
|
|
|
if not project_root:
|
|
|
|
set_project_root()
|
|
|
|
|
|
|
|
return project_root
|
|
|
|
|
|
|
|
|
|
|
|
def get_eslint_module_path():
|
|
|
|
return os.path.join(get_project_root(), "tools", "lint", "eslint")
|
|
|
|
|
|
|
|
|
|
|
|
def check_node_executables_valid():
|
2018-09-25 21:15:51 +03:00
|
|
|
node_path, version = find_node_executable()
|
2017-05-16 16:34:58 +03:00
|
|
|
if not node_path:
|
2018-09-25 21:15:51 +03:00
|
|
|
print(NODE_NOT_FOUND_MESSAGE)
|
|
|
|
return False
|
|
|
|
if not version:
|
|
|
|
print(NODE_MACHING_VERSION_NOT_FOUND_MESSAGE % NODE_MIN_VERSION)
|
2017-05-16 16:34:58 +03:00
|
|
|
return False
|
|
|
|
|
2018-09-25 21:15:51 +03:00
|
|
|
npm_path, version = find_npm_executable()
|
2017-05-16 16:34:58 +03:00
|
|
|
if not npm_path:
|
2018-09-25 21:15:51 +03:00
|
|
|
print(NPM_NOT_FOUND_MESSAGE)
|
|
|
|
return False
|
|
|
|
if not version:
|
|
|
|
print(NPM_MACHING_VERSION_NOT_FOUND_MESSAGE % NPM_MIN_VERSION)
|
2017-05-16 16:34:58 +03:00
|
|
|
return False
|
|
|
|
|
|
|
|
return True
|
2018-01-05 14:14:15 +03:00
|
|
|
|
|
|
|
|
|
|
|
def have_winrm():
|
|
|
|
# `winrm -h` should print 'winrm version ...' and exit 1
|
|
|
|
try:
|
|
|
|
p = subprocess.Popen(['winrm.exe', '-h'],
|
|
|
|
stdout=subprocess.PIPE,
|
|
|
|
stderr=subprocess.STDOUT)
|
|
|
|
return p.wait() == 1 and p.stdout.read().startswith('winrm')
|
2018-01-31 22:32:08 +03:00
|
|
|
except Exception:
|
2018-01-05 14:14:15 +03:00
|
|
|
return False
|