As of bug 1791454 m-c and autoland both also imply the toolchains
branch, which doesn't work for every kind of task, some of which are
really meant to only run on those branches.
Differential Revision: https://phabricator.services.mozilla.com/D164149
When running `./mach doc` locally it is a poor experience to have the build error out
due to fatal warnings, as it's possible the missing refs simply aren't implemented yet.
Or worse, it's possible that the developer ran `./mach doc <subtree>` and the missing
refs don't exist simply because they are outside of <subtree>.
This patch ensures we only enable fatal warnings in CI, or if the user opts into it with
the `--fatal-warnings` flag.
Differential Revision: https://phabricator.services.mozilla.com/D161633
Moving the comments outside of the `command` entry as they were preventing the
command to be executed since the command lines are then turned into a single line,
and the leading `#` character was commenting out the whole command.
Differential Revision: https://phabricator.services.mozilla.com/D155712
The fxms schema job has been updated with a script that writes out the test
corpus for the test. This means we no longer need to keep these JSON files in
tree, since the test will automatically generate them.
Differential Revision: https://phabricator.services.mozilla.com/D151985
To ensure that we don't ship a schema that breaks Experimenter, we now have
in-tree tests that validate FxMS messages against our schema using the same
JSON Schema evaluator (python-jsonchema).
Our test corpus is the same as test_PanelTestProvider.js. We cannot have
PanelTestProvider.jsm fetch the messages from the JSON due to fetch() not being
supported in the newtab npm tests.
Differential Revision: https://phabricator.services.mozilla.com/D151169
The Nimbus Features corresponding to FxMS messaging surfaces are actually
intended to map to FxMS message groups, which can accept *any* FxMS message.
The features have been updated with schemas that accept any FxMS message.
As part of this, all FxMS schemas have been updated with an `$id` so that they
can be bundled into feature schemas and have their internal `$ref`s work.
(Otherwise, a `$ref` would be relative to the top-level schema instead of the
sub-schema).
Schemas for individual message types are no longer exposed as resource:// URIs,
except in tests, as indivual schemas are no longer required at runtime.
Additionally, each FxMS schema has had its `template` field become required and
requires a constant value for that schema (e.g., Spotlight requires a template
value of "spotlight").
A test has been added to ensure that if any of the messaging surfaces schemas
change that the feature schemas are also updated. The feature schemas can be
regenerated via:
```
cd ./browser/components/newtab/content-src/asrouter/schemas
../../../../../../mach make-schemas.py
```
Differential Revision: https://phabricator.services.mozilla.com/D147332
The cargo-vet toolchain is auto-bootstrapped and setup for things to
work properly. We modify `mach vendor rust` to invoke `mach cargo vet`
instead of doing its own setup, but in a underhanded way to work around
bug 1772453.
Differential Revision: https://phabricator.services.mozilla.com/D148218
This is deliberately simple. Future improvements will report if the
vendoring doesn't produce the same content as what's in the tree, and
attach errors to a better location than the first line of Cargo.lock.
Differential Revision: https://phabricator.services.mozilla.com/D147466
updated patch for android_hardware_unittests.py, asking for a review- please look at the interdiff to see recent changes.
Differential Revision: https://phabricator.services.mozilla.com/D144985
See bug 1761441. The 'Bugzilla' task generates artifacts containing meta
information about files like a mapping of source files to bugzilla components.
It ran on mozilla-central which had the disadvantage that failures only got
detected after a merge of autoland to mozilla-central. This also broke
searchfox indexing.
The tier gets changed from 2 to 1 to get issues resolved by backout.
Differential Revision: https://phabricator.services.mozilla.com/D142210
In bug 1436263, I added a cpp-virtual-final.yml linter to warn about virtual function declarations that included more than one virtual function specifier `virtual`, `final`, or `override`.
I think we should remove this linter now because:
* It's just a style check and doesn't diagnose a real bug. Including more than one virtual function specifier (`virtual`, `final`, or `override`) is harmless and unambiguous, just unnecessary extra code.
* It has caused some engineer frustration because this style check caused their changeset to be backed out of autoland. Backing out and fixing these style issues are not a good use of sheriffs' or engineers' time.
* It doesn't catch all virtual/final/override style issues because:
* It can't analyze virtual function definitions that span multiple lines.
* It doesn't check for `virtual void Foo() override` because there are over 6000 cases already, so our code will never follow this style check consistently.
Differential Revision: https://phabricator.services.mozilla.com/D139454
Explicitly specify that the linter should run on all files (`*`), to
circumvent bug 1753701's behaviour of defaulting to VCS-changed files.
Differential Revision: https://phabricator.services.mozilla.com/D138173
Tweaks `./mach lint` behaviour to always fall back to only linting files
that have changed according to VCS - previously, this only happened if
no linter was provided.
Adjusts "am I at $topsrcdir" check to use `pathlib` to avoid mismatches
due to inconsistent capitalization or slash direction.
Updates CI references to explicitly provide `*` as the path to avoid
the only-lint-files-changed restriction.
Differential Revision: https://phabricator.services.mozilla.com/D137870
The platform(s) were not specified, and it seems when that is the case that
it will only run on linux by default. The platforms are now explicitly
set to include Windows, Linux, and Mac.
Differential Revision: https://phabricator.services.mozilla.com/D136214
This will ensure we don't accidentally cause bustage to graph generation with
any of the parameters checked into `taskcluster/test/params`.
This was previously being (sort of) tested by the `tgdiff` task. Now that this
test exists, we no longer need to rely on it.
I removed 'always-target' from the task since this now takes ~25 min to run and
which is the new bottleneck for reviewbot turn around times.
Differential Revision: https://phabricator.services.mozilla.com/D136514
The test itself takes around 25 minutes. If the task hits the clone step, it will take an additional 10minutes.
Note that there is also a slow clone issue where clone can take between 15 and 30 mn.
Differential Revision: https://phabricator.services.mozilla.com/D135476
This change adds a new lint `android-format` which enforces formatting of Java
code using google-java-format.
To run the lint simply run:
./mach lint -l android-format
This command also support automatically fixing all errors running by adding
--fix:
./mach lint -l android-format --fix
This change also removes all the formatting-related checkstyle checks which are
now implicitly enforced by the formatter.
Differential Revision: https://phabricator.services.mozilla.com/D127734
For a long time two copies of the 'taskgraph' module have existed in parallel.
We've attempted to keep them in sync, but over time they have diverged and the
maintenance burden has increased.
In order to reduce this burden, we'd like to re-join the two code bases. The
canonical repo will be the one that lives outside of mozilla-central, and this
module will depend on it. Since they both have the same module name (taskgraph)
we need to rename the version in mozilla-central to avoid collisions.
Other consumers of 'taskgraph' (like mobile repos) have standardized on
'<project>_taskgraph' as their module names. So replicating that here as well.
Differential Revision: https://phabricator.services.mozilla.com/D127118
Since all commits on non-try branches are public, vcs.base_ref was returning
the current revision each time and the diff task was always diffing against the
same revision twice.
By using 'json-automationrelevance' to determine the parent push, we can be
sure we're always diffing against the proper revision.
Depends on D125974
Differential Revision: https://phabricator.services.mozilla.com/D125975
For now this will only upload differences in tasks added / removed, until we
can figure out a way to remove ambient diffs from the bodies of the tasks (e.g
timestamps, revisions, etc).
Depends on D125866
Differential Revision: https://phabricator.services.mozilla.com/D125867
We set always-target: true for Python unittest tasks. This means they show up on every push (when appropriate files are modified). The reasoning behind this is that they run so fast anyway, and if you modify the relevant code then you almost always want to see the unittests for said code on your try pushes.
However on MacOS, the pool is limited. Given the differences between Linux and Mac for most Python unittests are likely extremely small, I don't think the cost of bogging down the Mac pool outweighs the benefits here.
Differential Revision: https://phabricator.services.mozilla.com/D125281
This is the last version that doesn't require Java 11, we will upgrade to
Gradle 7 once all components are ready (namely, apilint).
Co-authored-by: Jan-Erik Rediger <janerik@fnordig.de>
Differential Revision: https://phabricator.services.mozilla.com/D123569
Looks like 6G is not enough for an ASAN build when updating the gradle version.
I tried 8G and 16G on try but that's not enough either.
This also:
* Moves the asan job to `b-linux-large` as the `b-linux` builder does not have
enough memory to run this build.
* Stops running a full build during lints, which is not necessary (and
sometimes uses more memory than the build runner has, failing the lint).
Differential Revision: https://phabricator.services.mozilla.com/D123970
This is the last version that doesn't require Java 11, we will upgrade to
Gradle 7 once all components are ready (namely, apilint).
Co-authored-by: Jan-Erik Rediger <janerik@fnordig.de>
Differential Revision: https://phabricator.services.mozilla.com/D123569
This is the last version that doesn't require Java 11, we will upgrade to
Gradle 7 once all components are ready (namely, apilint).
Co-authored-by: Jan-Erik Rediger <janerik@fnordig.de>
Differential Revision: https://phabricator.services.mozilla.com/D123569
The wasi-sysroot toolchain contains both a sysroot for wasi and a
compiler-rt for clang. That makes it impractical to use as a
bootstrapped sysroot for wasm32-wasi builds of Spidermonkey.
We thus split the toolchain in two, one for the compiler-rt and one
for the sysroot. Ideally, the compiler-rt one would avoid building
clang/llvm the same way the sysroot one does, but that leads to
a case of chicken-and-egg, because the compiler-rt is needed to build
the clang toolchain. Eventually, the clang build would be split from
the addition of the compiler-rt, but we're not there yet.
Differential Revision: https://phabricator.services.mozilla.com/D122402
Followup for bug 1719229 ; some builds have not been tweaked to use the
x86_64-linux-gnu sysroot.
In a few cases, this also use a sysroot for the target part when that
wasn't already the case.
Differential Revision: https://phabricator.services.mozilla.com/D119957
In cross-compilation setups (x86_64 host, i686 or aarch64 target), we're
going to need two sysroots. Obviously, we need the sysroot paths to be
different in that case, so the sysroot path themselves need to contain
some distinctive name, and we'll use the `target.toolchain` name for
that (the target triplet with the vendor/machine stripped out).
Because the path name needs to be reflected in the artifact name as well
as the toolchain name, we also change them.
And because the current prefix in the toolchain name is now redundant
with the suffix, we remove the prefix, and allow the bootstrapping
mechanism to try toolchains without the prefix.
Differential Revision: https://phabricator.services.mozilla.com/D119846
This patch adds a new linter that will error when new code mentions any one of
the following strings:
* `CoInitialize`;
* `CoInitializeEx`;
* `OleInitialize`;
* `RoInitialize`;
* `CoUninitialize`;
* `OleUninitialize`; and
* `RoUninitialize`.
Since I don't care about context, and just want to flag code containing these
names, I opted for a `regex` linter.
Yes, the regex does match a few strings beyond the above list (in particular, it
also matches additional strings that end with an `Ex` suffix), but since
functions with those names don't exist anyway (and would be errors in their own
right), I am not concerned about it.
All existing occurrences have been added to the exclusion list, with the
intent of removing most of them over time.
Differential Revision: https://phabricator.services.mozilla.com/D119129
The `mozbase` modules were being unconditionally added to the
`sys.path` regardless of the Mach command being run, so there isn't
much value keeping them in a separate file. Besides, all other
source module paths are described in `common_virtualenv_packages`,
why is `mozbase` special?
In the future, we're going to want to make improvements here (such as:
there's a difference between informing mach of first-party code
versus defining which third_party vendored packages should be in scope,
and that workflow difference should be represented in-code).
It's useful to peel out the existing, less useful abstraction before
we can build a stronger one.
Differential Revision: https://phabricator.services.mozilla.com/D117711
Marco Castelluccio
Mike Hommey
Mark Banner
Andrew Halberstadt
Cristian Tuns
Nick Alexander
Makoto Kato
Tom Ritter
Julien Cristau
Brenden Hyde
Nicolas Chevobbe
Cosmin Sabou
Henrik Skupin
Michelle Goossens
Barret Rennie
Iulian Moraru
Joel Maher
Butkovits Atila
Luca Greco
Sebastian Hengst
Julian Descottes
Chris Peterson
Thomas Wisniewski
Mitchell Hentges
Dan Mosedale
ahochheiden
Geoff Brown
Sylvestre Ledru
Agi Sferro
Andi-Bogdan Postelnicu
Andrew Halberstadt
Agi Sferro
Alexandru Michis
Aaron Klotz