Mochitest no longer passes in debug_args in via the commandline. Instead, it passes
them in via a marionette chrome script, meaning they no longer need to be escaped.
Since web-platform-tests still passes debug_args on the commandline, we can't simply
remove the feature entirely. Instead, just make mochitest ignore requiresEscapedArgs.
MozReview-Commit-ID: KBVviGpkvQS
--HG--
extra : rebase_source : 8b3e63b64e608a50e6849affe5ba7c2be323c76c
This reduces sizeof(PrefHashEntry) from 40 bytes to 32 bytes on 64-bit
platforms, which reduces the entry storage of |gHashTable| from 160 KiB to 128
KiB in every process.
We can now define a list of "tags" for a task. Specifying "-j <tag>"
in Try syntax will run all tasks having that tag.
MozReview-Commit-ID: Ih9Z0tRZ5VA
--HG--
extra : rebase_source : 5d8bab98c2793ff3b71e36e7a4d14dca60bba46c
This uses a repacked version of the upstream 1.8 nightly
builds. We need 1.8 for WinXP support, but it's safe to
use nightly until this stablises because other platforms
are using stable rust and will catch any nightly-only
feature use.
For these builds I used the channel-rustc-nightly manifest instead
of the older channel-rust-* manifest, to get the separate std packages.
tar xf rustc-nightly-i686-pc-windows-msvc.tar.gz
rustc-nightly-i686-pc-windows-msvc/install.sh --prefix=rustc/
tar xf rust-std-nightly-i686-pc-windows-msvc.tar.gz
rust-std-nightly-i686-pc-windows-msvc/install.sh --prefix=rustc/
tar cjf rustc.tar.bz2 rustc/*
Firefox's automation currently tends to run all the jobs all the time.
It is wasteful to do this. For example, running ESLint when the commit
only changes a .cpp file adds no value.
This commit adds support for only running tasks when certain files
change. The new-style tasks introduced by the previous commit have been
taught a "when" dictionary property that defines conditions that should
hold for the task to be executed. We define a "file_patterns" list that
defines lists of mozpack path matching expressions that will be matched
against the set of files changed by the changesets relevant to the
changeset being built. The eslint task has been updated to only run if
files related to it change.
Because conditions may not be accurate, we add a CLI argument to ignore
conditions and force all would-be-filtered tasks to run.
MozReview-Commit-ID: 3OeBSKAQAeg
--HG--
extra : rebase_source : 9a7047c6f366250fc0feaee32b5fb7944dfdc7a7
Currently, tasks are either "build" or "test" tasks. And "test" tasks
are dependent on "build" tasks, so they are effectively an extension of
"build" tasks.
Not everything is a "build" task. Not everything is associated with a
specific platform.
This commit introduces support for defining non-build "tasks" under the
"tasks" top-level element of a jobs YAML file. Interally, they are
treated as "build" tasks but are declared differently.
By default, all these tasks run.
The -j/--job argument has been added to the try syntax parser. It
specifies an opt-in list of these non-build tasks to run. By default, it
runs all of them.
The eslint-gecko "build" task has been moved to this new mechanism.
Documentation for the new task type have been added.
There is definitely some wonkiness in this implementation. For example,
there are references to "build_name," "build_type," and "build_product,"
which arguably are no longer relevant to generic tasks. However, they
appear to be so integrated into task processing (including route names)
that I'm a bit scared to change them.
MozReview-Commit-ID: BY219tLFb6Z
--HG--
extra : rebase_source : 743f46a06404c0b31383de419dd6a8d207bafbb6
It is possible to hook up in-tree documentation to Sphinx. Convert the
one-off README.md to ReStructuredText and add it to the Sphinx docs.
I added a moz.build file under testing/ because I don't think it is
appropriate for the Sphinx directive to live in the root moz.build file.
MozReview-Commit-ID: 90tCb7mA63C
--HG--
rename : testing/taskcluster/README.md => testing/taskcluster/docs/index.rst
extra : rebase_source : 9312445aa17a1a2b03195a4f18442f8a8a0d8fe9
We're about to introduce a mechanism to influence which tasks run based
on what files change. To help debug what's happening, print out the list
of commits that influence the task selection.
MozReview-Commit-ID: Kfj2pf1PSIS
--HG--
extra : rebase_source : f8f76056e34c1ee2a7cf936464f2cd44d4838496
Over in bug 1247802 we deployed a new JSON web API on hg.mozilla.org
that returns JSON metadata for changesets that are relevant for build
automation. It returns a superset of what is returned by the pushlog
JSON API. So we switch to it.
MozReview-Commit-ID: 6X3NANo1mgq
--HG--
extra : rebase_source : 09249a7be3d46eee5c86bb696243b047da424239
In preparation for adding more content that isn't strictly related to
pushlog info.
MozReview-Commit-ID: I4c8KAutUDm
--HG--
extra : rebase_source : 590e940999207e2b20f3921889bf0acee54b1258
Before, we attempted to build and query a URL that potentially had
"None" in it. This printed some wonky messages in the log and may have
contributed to added latency due to the HTTP request that was doomed to
fail.
MozReview-Commit-ID: JrR5PK33vCn
--HG--
extra : rebase_source : 8fcbb2216cf3c6379865b8a2314ead9307175fd2
requests should *always* be used for performing HTTP requests because it
has a better API *and* has sane security defaults compared to the HTTP
request APIs in the Python standard library. Although, Python 2.7.9+
does have slightly saner defaults in the standard library. I still trust
requests more.
MozReview-Commit-ID: GqohpfYYGBw
--HG--
extra : rebase_source : e6850a80818d73205a22ea4ba92be9e0ec43a473
The function will soon query something that isn't limited to pushlog
info. Rename it accordingly.
MozReview-Commit-ID: 68UrMmLYARD
--HG--
extra : rebase_source : 9f63474301f64661fd16e5cef9dd2adfcfc36a40
Two MSimdBox instructions with the same SimdType must have identical template
objects, but they do not need to have identical initial heaps. One could
represent a pre-tenured SIMD object allocation.
MozReview-Commit-ID: ITymizUKjlN
--HG--
extra : rebase_source : f130b356de408bbaeecf3ff1070266e0223d4aaa