After fixing the absolute path issue in codespell, I noticed that the stylish
formatter doesn't indent lint issues that don't have a column properly. This
was never noticed before since most other linters have a column attribute.
Depends on D4012
Differential Revision: https://phabricator.services.mozilla.com/D4013
--HG--
extra : moz-landing-system : lando
Currently there are 3 things that can impact the result of a lint run:
1. The list of lint issues found
2. The set of failures that happened during the setup phase
3. The set of failures that happened during the execution phase
All three of these things are stored as instance variables on the LintRoller
object, and then passed into a formatter when it comes time to print the
results. I'd like to add even more things that can impact the result, and it
became clear that the current scenario does not scale well.
This patch moves all data that could impact the end result of a lint run off of
the LintRoller object and onto a new 'result.ResultSummary' class. To avoid
confusion, this patch also renames the 'result.ResultContainer' class to
'result.Issue'.
With this new nomenclature:
result -> overall state of an entire lint run (can comprise multiple linters)
issue -> one specific lint infraction (at either 'warning' or 'error' level)
failure -> a non-recoverable error in the linter implementation itself
A "result" is comprised of 0 or more "issues" and 0 or more "failures".
Differential Revision: https://phabricator.services.mozilla.com/D3819
--HG--
extra : moz-landing-system : lando
As of this patch, any lint issue at the "warning" level will *only* be displayed
if --warnings is passed in. This gives us some flexibility to track issues that
are "recommended to fix" but that aren't required (aka don't cause a backout).
I think it would be ideal if the reviewbot ran with warnings enabled, and CI
ran without warnings. This way these issues will be surfaced to developers
(and hopefully get fixed prior to landing), but developers will always be able
to ignore them if the situation warrants it.
Since the last change converted everything to use errors, this patch should
be a no-op for now. However as we move forward (and potentially decide that
certain types of lint issues should result in a backout), this feature will
start seeing more and more use.
Depends on D3820
Differential Revision: https://phabricator.services.mozilla.com/D3821
--HG--
extra : moz-landing-system : lando
moz.configure looks for rustc/cargo on PATH and in ~/.cargo/bin.
Bootstrap only looks on PATH and not in ~/.cargo/bin, though it is smart
enough to complain if rustc/cargo can't be found on PATH and you have
them in ~/.cargo/bin. Bootstrap should look in both places by default,
and be content if it finds them wherever they are, so long as
moz.configure can find them.
The state directory is in $HOME by default, so should be fine to just create it
if we get --no-interactive I think.
Differential Revision: https://phabricator.services.mozilla.com/D3838
By default, when the launcher process is enabled, it does not wait for the
browser process to complete before terminating. mach run expects its child
process to keep running until the browser is terminated.
If we pass -wait-for-browser to the launcher process, the launcher will not
terminate until the browser process has finished, thus preserving the existing
semantics.
--HG--
extra : amend_source : cc848f955e14d7a97c1c506247fa2788261912f2
armasm64 doesn't accept the same options as its x86-ish counterparts,
and passing options it doesn't understand causes assembly to fail. So
let's just not pass any flags to the assembler for the moment.
If the wpt manifest format changes we bump the version number, causing
loading the old manifest to throw an error. We weren't correctly
handling this error when trying to update the manifest (by creating a
new empty manifest) so updates after the version number changed broke.
MozReview-Commit-ID: 4H1nMtRI9PZ
Differential Revision: https://phabricator.services.mozilla.com/D3771
--HG--
extra : moz-landing-system : lando
External systems such as the generic ingestion service will want to work with
the more standard json-schema format. This commit adds a script to convert the
voluptuous schema to json-schema format using the `luscious` Python module.
Since that module has not been updated recently, we install and use a fork with
some changes.
Since this is a single-purpose command that's unlikely to be used by many
people it's not implemented as a mach command, but simply a standalone script
that can be invoked via `mach python`.
Differential Revision: https://phabricator.services.mozilla.com/D2841
--HG--
extra : rebase_source : d35ed221d05d1d56b96604b931c22b700c10e476
This change adds a voluptuous schema for build system telemetry, replacing
the existing json schema file. Using voluptuous will make it easier to work
with the schema from Python code in the build system. A future commit will
use a Python module to provide a mach command to convert the voluptuous
schema to json schema format for consumption by other systems.
Differential Revision: https://phabricator.services.mozilla.com/D2840
--HG--
extra : rebase_source : 067995385334d1dbc123f2db4245ef4e69d076c3
This excludes directories, and returns true only if it's an executable file.
Differential Revision: https://phabricator.services.mozilla.com/D3366
--HG--
extra : moz-landing-system : lando
If you specify 'mk_add_options MOZ_PARALLEL_BUILD=X' in your mozconfig,
this variable ends up being passed into client.mk, which tells the make
backend to use that as the number of parallel jobs. However, there is no
equivalent in alternate backends aside from specifying '-jX' at the
commandline on each build invocation.
Rather than making a new mechanism to do this, we can check the
mozconfig for the MOZ_PARALLEL_BUILD flag and use that number for the
jobs parameter if no override was specified on the commandline.
MozReview-Commit-ID: 4YHG30N6tmi
Differential Revision: https://phabricator.services.mozilla.com/D3362
--HG--
extra : moz-landing-system : lando
And require it for taskcluster build already, because it doesn't harm and lets
me put all the yml changes in the same commit.
I gave up cross-compiling for OSX after a few tries and after realizing it
wasn't enough with cctools and such, but that I also needed the Mac SDK, for
which I don't have permission...
Differential Revision: https://phabricator.services.mozilla.com/D2664
--HG--
extra : moz-landing-system : lando
