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
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
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
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
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
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
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
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
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
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
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
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
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
We only support building with VS2013 and VS2015. Remove references
to older versions in the Visual Studio build backend.
MozReview-Commit-ID: 6QTSylqLwLF
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
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
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
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
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
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
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
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
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
