This is a really simple and ugly formatter that is compatible with
treeherder's error highlighting mechanism. It is designed to be identical
to the current eslint output on treeherder:
https://dxr.mozilla.org/mozilla-central/rev/4d63dde701b47b8661ab7990f197b6b60e543839/tools/lint/eslint-formatter.js
Eventually eslint will also use this and we can remove that file. Once
bug 1276486 is fixed, we can make this look a little nicer. But for now
it gets the job done.
MozReview-Commit-ID: CwfWPcwWFxF
--HG--
extra : transplant_source : %F3PJ%CB%27%A5%82U%D2%CF%B3%9E%A7%9F%0F%A4%F4%E9%5D%BB
This is a really simple and ugly formatter that is compatible with
treeherder's error highlighting mechanism. It is designed to be identical
to the current eslint output on treeherder:
https://dxr.mozilla.org/mozilla-central/rev/4d63dde701b47b8661ab7990f197b6b60e543839/tools/lint/eslint-formatter.js
Eventually eslint will also use this and we can remove that file. Once
bug 1276486 is fixed, we can make this look a little nicer. But for now
it gets the job done.
MozReview-Commit-ID: CwfWPcwWFxF
--HG--
extra : rebase_source : 8dd39aefec1064e0836c847c6d223db43df4755b
These variables specify a version of Mercurial that is considered
modern and won't trigger giant warnings about being out of date.
We bump to 3.7.3 because 3.7.3 contains security fixes and it is
important for as many users as possible to get these security fixes.
We also update the messaging to indicate security issues with older
releases.
MozReview-Commit-ID: H4utKINrW0V
--HG--
extra : rebase_source : 5247fec94d7df351ef3c7bb2aa60396bb19a6196
extra : amend_source : 70b9aa52cde71d11e2b6d65a1a83567b8a0c7965
Now that the VisualStudio backend will no-op if nothing has changed, it
should be safe to always run this backend.
On first run, backend generation takes ~3.5s on my machine. On subsequent run,
it takes ~1.5s. Wall time for a no-op config.status is now ~15.7s. We could like
make the Visual Studio backend faster by not writing so many project files.
But this would require consolidating libraries in moz.build files. And that's
out of scope for this change.
We drop the check for MSVS_VERSION because it won't always be defined on
MinGW/GCC builds. We simply default to "2015" if it isn't set.
MozReview-Commit-ID: 5W38HMGmcuV
--HG--
extra : rebase_source : 302d76277058819c115f3c2518b8cb2067971950
extra : source : 408319d87eacb28848efeab0346eb815440adade
Should be a stopgap until bootstrapper is ported to Python 3.
MozReview-Commit-ID: 2NNC3jMftr9
--HG--
extra : rebase_source : 9d903dc0830369a84206c56136fb90006f9ad842
There is probably a way to dynamically retrieve the version. But rather
than take the chance we'd query the wrong thing, let's just parse the
version that Visual Studio writes to the solution file when saving it and
use it.
With this change, generating the VisualStudio build backend should not change
any files unless the build config has changed. This means we can generate
Visual Studio files at will without causing Visual Studio to complain
about the solution and other files changing and needing reloading.
MozReview-Commit-ID: 1udZ72SLEzP
--HG--
extra : rebase_source : d15bff5b30a021dc1180e48fb7bb0d6c84871b69
Visual Studio will write this variable to an ancient Visual Studio
version (2010 I believe) if we don't specify it. Explicitly write the
variable to the minimum Visual Studio version we support.
MozReview-Commit-ID: 8Y0im48OM2G
--HG--
extra : rebase_source : 7b1f4cfe778c6258dce068b2aec8b6acd8e85102
Upon further examination, VS2013 and VS2015 share the same file format
version. They also write the internal version number in a comment, not
the user-facing production version.
MozReview-Commit-ID: 92HB0pEzeI6
--HG--
extra : rebase_source : ebf00ae704ccd44415f8d7054359c87287734926
GetConsoleWindow() can return NULL. Previously, we may have passed a NULL
console reference into FlashWindowEx(). On my machine (when running in a
console), passing NULL doesn't seem to cause an error. But since we have
a report of this function hanging, it is quite possible it can cause
hangs in other scenarios. Since a NULL console won't result in any
notification, let's not call FlashWindowEx() when no console is available.
MozReview-Commit-ID: LrKX8weUkzX
--HG--
extra : rebase_source : 6c3fc724dbc038f6b51bbdc14d985202c47074e8
Before, ./mach build would try to use terminal-notifier after building, but would not be able to since it isn't installed.
MozReview-Commit-ID: 4oBAVfOdcNs
--HG--
extra : rebase_source : 0930e9d4dc038e59f18beb85b4911552c76c0eed
The label has been there for years. It isn't really experimental.
The Visual Studio solution still leaves a lot to be desired. But
let's not scare people away by calling it experimental.
MozReview-Commit-ID: 7UvsbsKNnWw
--HG--
extra : rebase_source : a7d3f824859629297a782a0883ebf78af1d8fa70
By using self._write_file() and FileAvoidWrite, we avoid writing files
unless they change. This means that Visual Studio won't want you to
reload the solution and projects whenever the backend is generated.
This means you can regenerate the backend all you want and chances are
it won't disrupt your Visual Studio experience.
Since self._write_file() creates parent directories for us, we were
able to remove this code.
If you run `mach build-backend --diff` with this commit, output will
change. For reasons I don't understand, we were producing XML with
e.g. \r\r\n sequences. This patch appears to restore \r\n. How
we got \r\r I don't know because I can't find anywhere in the code
where that can occur. But this commit does appear to restore sanity.
Also, it appears modern versions of Visual Studio (perhaps only VS2015)
doesn't write your project files. When I initially implemented Visual
Studio project generation several years ago, as soon as you loaded
the solution and hit "Save All" Visual Studio would re-save your files
using a slightly different formatting (it did some gnarly things with
XML indentation). VS2015 doesn't do this. So your files on disk should
be unmodified for longer, making Visual Studio a more viable development
environment. Yay.
MozReview-Commit-ID: 7CSk0dsLOli
--HG--
extra : rebase_source : 3cd04ba8ffed8fc8880de66b1f4fce1f6300b51c
Currently, self._write_file() instantiates FileAvoidWrite instances
with the default mode of 'rU' which uses universal newlines (\n).
Visual Studio project files use CRLF newlines. We want to use
self._write_file() in the Visual Studio backend (which predates
self._write_file). Prepare for this by passing the mode argument
through.
MozReview-Commit-ID: LHCUf3IrpJ8
--HG--
extra : rebase_source : be08d8e043ef625f8f846c38446e1430e072a665
If we're running VS2013, we generate VS2013 files. If we're running VS2015,
we generate VS2015 files. If we don't have a Visual Studio version
defined, refuse to generate project files (hopefully this doesn't
happen in the real world but I'm sure someone will complain if it does).
MozReview-Commit-ID: 5GdsbGmWPLB
--HG--
extra : rebase_source : 1a50c0fa5b7980ad25fb3ed3c1ec2c95f16996b6
We only support building with VS2013 and VS2015. Remove references
to older versions in the Visual Studio build backend.
MozReview-Commit-ID: 6QTSylqLwLF
--HG--
extra : rebase_source : d654f0e415dd5c1bfa1258633e26d467bea5535a
These imports make an out-of-tree build of SpiderMonkey depend on
the reftest module, which means SpiderMonkey implicitly depends on
layout/tools/reftest.
Firefox automation now uploads resource usage JSON files as
job artifacts (see bug 1272202). Now that the build system
writes the same data format and `mach resource-usage` can
read this data format, let's teach `mach resource-usage`
to load arbitrary URLs. This allows people to view system
resource usage for arbitrary jobs in automation.
Currently, you have to look at Treeherder to find the URL to
the build-resources.json artifact. Perhaps in the future
we can make finding the URL easier. Or we could integrate
source resource viewing into Treeherder itself (this is
probably preferred).
This commit continues the tradition of `mach resource-usage`
being a hacked up mess. Instead of loading the URL in
the browser, we download the URL from Python then serve it
from the HTTP server running as part of `mach resource-usage`.
This is somewhat horrible. But it was easiest to implement.
It also conveniently bypasses any cross origin request
restrictions the browser may impose. So it is useful.
MozReview-Commit-ID: IR1Cfs7SrRN
--HG--
extra : rebase_source : b33231d482ca891c1b3331f472009518bf57f8c3
We currently have our own system monitor serialization in
building.py. It predates as_dict() from mozsystemmonitor. Let's
use the "upstream" data format so we only have a single format
to consume.
This change required updating the in-tree resource viewer to
be compatible with the new data format.
This commit stops short of getting rid of the existing
data massaging code in building.py. Another day perhaps.
MozReview-Commit-ID: 1OJrSiyJjMX
--HG--
extra : rebase_source : 9782b2164d1735ed0872fe8c1637204d5b3b1313
For now, only the following two directories will be linted:
python/mozlint
tools/lint
New directories can be added by adding them to the 'include'
directive in tools/lint/flake8.lint. They all default to the
configuration specified in topsrcdir/.flake8. Subdirectories
can override this configuration by creating their own .flake8
file.
MozReview-Commit-ID: Eag48Lnkp3l
--HG--
extra : rebase_source : 6d98c9fef80055a48cc2622848aa04c3045b747e
The current algorithm for filtering down tests is too naive. For example, given the following
directory structured:
parent
- foo
- bar
- baz
And the following include/exclude directives:
include = ['foo']
exclude = ['foo/bar']
Then running ./mach lint parent and ./mach lint foo/baz should both lint all files in baz but
no files in bar. This provides a nice way to include/exclude directories, while allowing the
underlying linters to find appropriate files to lint *within* those directories.
tl;dr - Straight file paths (no globs) will be passed straight to the underlying linter as is.
While paths with globs will first be resolved to a list of matching file paths.
MozReview-Commit-ID: Eag48Lnkp3l
--HG--
extra : rebase_source : 18ce2231bc4198b1e811d39f9803f0d5e03d982e
So a few changes here:
- node_modules is downloaded using tooltool so that we dont need to rely on external infrastructure.
- We have a npm-shrinkwrap.json file that version locks all of our node packages.
- eslint, eslint-plugin-mozilla etc. are now all installed locally.
In reality this means that we don't hit the network and we don't force users into installing global packages.
./mach eslint --setup has also been improved. We install packages locally and display the path of the user's eslint binary (useful for configuring editors).
eslint-plugin-mozilla has been moved from testing/eslint-plugin-mozilla to /testing/eslint/eslint-plugin-mozilla.
The node_modules directory for eslint and other plugins is located in testing/eslint/.
MozReview-Commit-ID: 4SFSxzka6BS
--HG--
rename : testing/eslint-plugin-mozilla/LICENSE => testing/eslint/eslint-plugin-mozilla/LICENSE
rename : testing/eslint-plugin-mozilla/docs/balanced-listeners.rst => testing/eslint/eslint-plugin-mozilla/docs/balanced-listeners.rst
rename : testing/eslint-plugin-mozilla/docs/import-browserjs-globals.rst => testing/eslint/eslint-plugin-mozilla/docs/import-browserjs-globals.rst
rename : testing/eslint-plugin-mozilla/docs/import-globals.rst => testing/eslint/eslint-plugin-mozilla/docs/import-globals.rst
rename : testing/eslint-plugin-mozilla/docs/import-headjs-globals.rst => testing/eslint/eslint-plugin-mozilla/docs/import-headjs-globals.rst
rename : testing/eslint-plugin-mozilla/docs/index.rst => testing/eslint/eslint-plugin-mozilla/docs/index.rst
rename : testing/eslint-plugin-mozilla/docs/mark-test-function-used.rst => testing/eslint/eslint-plugin-mozilla/docs/mark-test-function-used.rst
rename : testing/eslint-plugin-mozilla/docs/no-aArgs.rst => testing/eslint/eslint-plugin-mozilla/docs/no-aArgs.rst
rename : testing/eslint-plugin-mozilla/docs/no-cpows-in-tests.rst => testing/eslint/eslint-plugin-mozilla/docs/no-cpows-in-tests.rst
rename : testing/eslint-plugin-mozilla/docs/reject-importGlobalProperties.rst => testing/eslint/eslint-plugin-mozilla/docs/reject-importGlobalProperties.rst
rename : testing/eslint-plugin-mozilla/docs/var-only-at-top-level.rst => testing/eslint/eslint-plugin-mozilla/docs/var-only-at-top-level.rst
rename : testing/eslint-plugin-mozilla/lib/globals.js => testing/eslint/eslint-plugin-mozilla/lib/globals.js
rename : testing/eslint-plugin-mozilla/lib/helpers.js => testing/eslint/eslint-plugin-mozilla/lib/helpers.js
rename : testing/eslint-plugin-mozilla/lib/index.js => testing/eslint/eslint-plugin-mozilla/lib/index.js
rename : testing/eslint-plugin-mozilla/lib/processors/xbl-bindings.js => testing/eslint/eslint-plugin-mozilla/lib/processors/xbl-bindings.js
rename : testing/eslint-plugin-mozilla/lib/rules/.eslintrc => testing/eslint/eslint-plugin-mozilla/lib/rules/.eslintrc
rename : testing/eslint-plugin-mozilla/lib/rules/balanced-listeners.js => testing/eslint/eslint-plugin-mozilla/lib/rules/balanced-listeners.js
rename : testing/eslint-plugin-mozilla/lib/rules/import-browserjs-globals.js => testing/eslint/eslint-plugin-mozilla/lib/rules/import-browserjs-globals.js
rename : testing/eslint-plugin-mozilla/lib/rules/import-globals.js => testing/eslint/eslint-plugin-mozilla/lib/rules/import-globals.js
rename : testing/eslint-plugin-mozilla/lib/rules/import-headjs-globals.js => testing/eslint/eslint-plugin-mozilla/lib/rules/import-headjs-globals.js
rename : testing/eslint-plugin-mozilla/lib/rules/mark-test-function-used.js => testing/eslint/eslint-plugin-mozilla/lib/rules/mark-test-function-used.js
rename : testing/eslint-plugin-mozilla/lib/rules/no-aArgs.js => testing/eslint/eslint-plugin-mozilla/lib/rules/no-aArgs.js
rename : testing/eslint-plugin-mozilla/lib/rules/no-cpows-in-tests.js => testing/eslint/eslint-plugin-mozilla/lib/rules/no-cpows-in-tests.js
rename : testing/eslint-plugin-mozilla/lib/rules/reject-importGlobalProperties.js => testing/eslint/eslint-plugin-mozilla/lib/rules/reject-importGlobalProperties.js
rename : testing/eslint-plugin-mozilla/lib/rules/var-only-at-top-level.js => testing/eslint/eslint-plugin-mozilla/lib/rules/var-only-at-top-level.js
rename : testing/eslint-plugin-mozilla/moz.build => testing/eslint/eslint-plugin-mozilla/moz.build
rename : testing/eslint-plugin-mozilla/package.json => testing/eslint/eslint-plugin-mozilla/package.json
extra : rebase_source : cf689f6cc170b9a22018c981a768f545f952e019
Currently a bug in python (https://bugs.python.org/issue8296) is preventing a KeyboardInterrupt from
reaching the parent process, meaning we can't kill the process with SIGINT. There is a workaround to
this bug, but instead I decided to ignore SIGINT in the parent process completely. Now, each child
process is responsible for handling SIGINT on its own. Since child processes should all shutdown
relatively quickly anyway, this effectively also ends the parent process.
The benefit of doing it this way is that each child process can return the results they have collected
to date. So when a developer hits Ctrl-C, they'll still see some (but not all) formatted lint output.
The downside is that a poorly implemented external linter could block the parent process from exiting
quickly, but if this happens we should just fix the linter.
MozReview-Commit-ID: 2tRJgtmoPYP
--HG--
extra : rebase_source : e72282bcc29c9b22690168dc973a817236cdf8ca
Firefox automation now uploads resource usage JSON files as
job artifacts (see bug 1272202). Now that the build system
writes the same data format and `mach resource-usage` can
read this data format, let's teach `mach resource-usage`
to load arbitrary URLs. This allows people to view system
resource usage for arbitrary jobs in automation.
Currently, you have to look at Treeherder to find the URL to
the build-resources.json artifact. Perhaps in the future
we can make finding the URL easier. Or we could integrate
source resource viewing into Treeherder itself (this is
probably preferred).
This commit continues the tradition of `mach resource-usage`
being a hacked up mess. Instead of loading the URL in
the browser, we download the URL from Python then serve it
from the HTTP server running as part of `mach resource-usage`.
This is somewhat horrible. But it was easiest to implement.
It also conveniently bypasses any cross origin request
restrictions the browser may impose. So it is useful.
MozReview-Commit-ID: IR1Cfs7SrRN
--HG--
extra : rebase_source : 91f5f807c19643ac4d1edb8f6652110813f7e53f
We currently have our own system monitor serialization in
building.py. It predates as_dict() from mozsystemmonitor. Let's
use the "upstream" data format so we only have a single format
to consume.
This change required updating the in-tree resource viewer to
be compatible with the new data format.
This commit stops short of getting rid of the existing
data massaging code in building.py. Another day perhaps.
MozReview-Commit-ID: 1OJrSiyJjMX
--HG--
extra : rebase_source : b7c7824b84110f118223dc483b03398855fe9965
Origins will be set for any caller of CommandLineHelper.add, but will only
be propagated if args are added to extra_args. This results in an incorrect
origin recorded for mozconfig injected arguments.
MozReview-Commit-ID: 9mJCaNHyd5C
