This test-only "run-on-projects" option indicates that the test should run on
exactly the projects where its parent build runs. This avoids the situation
where a build is configured to *not* run on a project, but some wayward test
didn't get the memo and "pulls in" the build anyway. This has been
particularly problematic with win64-asan/opt.
MozReview-Commit-ID: 8UP6FsXBohy
--HG--
extra : rebase_source : 237ea2898767da8e4561d1f6884e5add92a7bde2
A quick fix for hazard bustage by increase the NUM_ALLOWED_WRITE_HAZARDS
from 3 to 7 is pushed in bug 1348173 comment 37. In this bug, we shall do
the actual fix and restore the NUM_ALLOWED_WRITE_HAZARDS.
The -moz-border-*-colors bindings trigger errors because they're using
outparams (nsStyleBorder) which further manipulate its member (mBorderColors)
which is a double raw pointers. Since we don't have the ability to
whitelist the indirect access to mBorderColors[x] list, we can only add
them to the ignoreContents for now.
We might be able to move these bindings to the whitelist of the above
treatAsSafeArgument function, if we could refactor mBorderColors to use
nsTArray directly.
MozReview-Commit-ID: 2cQz58K2A10
--HG--
extra : rebase_source : af2b5b944fb9d19fe28f57eaa37f77174d48bfa4
Full Firefox on Linux can now be run with a --headless flag.
This includes seven parts:
1) Running all marionette tests in headless mode.
2) Prevents crashes where Firefox calls into GTK.
3) Adds a headless screen helper which supports changing the headless
screen size with the environment variables MOZ_HEADLESS_WIDTH and
MOZ_HEADLESS_HEIGHT.
4) Supports simulating moving a headless window.
5) Adds a stubbed out nsSound implementation.
6) Supports simulating size mode changes of headless windows.
7) Adds the --headless flag for Firefox.
Tasks should be assigned a priority based on the branch they originated from. It
is important that certain branches receive preferential treatment, such as a release
branch task being executed before a task from Try. Branch priority mirrors
the priorities defined within buildbot.
MozReview-Commit-ID: 8qR9F34lzzc
--HG--
extra : source : 6a2176a264959e19e4a4cbcb18fd47b9653745f8
This commit adds the target_tasks method to trigger nightlies, and the unscheduled cron entry.
MozReview-Commit-ID: ELcZcUGPg2T
--HG--
extra : rebase_source : 4c7093066d4102022a851c34a32f6ff825a5a541
While here, since the tooltool call from the cctools build scripts was
verbose, make the one in tooltool-download.sh verbose. It will benefit
the other things using tooltool-download.sh, making debugging easier
when one needs to look at the tooltool download logs...
--HG--
extra : rebase_source : eef0117ca25800431f4ded246a57edf085cac5c0
This uses the email provided by mozilla-taskcluster to find who to
email about failed decision tasks. It also adds some validation of
the try syntax that we've previously ignored.
Any platforms or build types specified in try sytax that don't exist
in the full task graph will throw an error.
MozReview-Commit-ID: JOKkLle7hEe
--HG--
extra : rebase_source : 65299c95c60bcb3c6a295b1f8f2f18477c2852db
Also change the README of the dmg tarball to point to the artifact url
directly.
--HG--
extra : rebase_source : efc96cf468fd2dcccf727b4c2f32c8d9e0d1bc40
Also use the same cctools as cross-mac builds of Firefox.
Do dummy changes to the corresponding build scripts so that the builds
are force triggered (toolchain builds are not triggered automatically
when the tooltool manifest they use changes yet).
--HG--
extra : rebase_source : 699143de819c29c98ca31308ac502f9331123403
We'd like to ensure that both parallel and serial traversal in Stylo are
tested on automation. Since e10s is the future, we've chosen to force
parallel traversal on during e10s tests, and force serial traversal on
during non-e10s tests.
For some reason, the locales package is not installed anymore during the
docker image build, which leads to the locale-gen command failing, since
it's not there.
--HG--
extra : rebase_source : 0a152499c623a00d27d8b916c472e5d5980d8193
The cctools-port build scripts were pulling and building the master branch
of the cctools-port repo, which means they'd build whatever was there
when they get triggered. I think this was copied from my build-cctools
script which did the same thing, so it's my fault in the end! This patch
pins a revision in the script so we'll build the same thing until we
explicitly update.
I also fixed the scripts to use git instead of tc-vcs, since tc-vcs prints
misleading error messages, and nothing else uses that anymore.
Finally, I removed the build-cctools script, since all the builds are using
cctools-port now so it doesn't serve any useful purpose.
MozReview-Commit-ID: 5myqHS4duor
--HG--
extra : rebase_source : 11231cbe49c7ba830a880bfa4600f0a24d61471d
Mercurial uses the latest version of TLS that is both supported by
Python and the server.
In automation, the servers we care about should all support TLS 1.2.
The Python side is trickier. Modern versions of Python (typically 2.7.9+)
support TLS 1.1 and 1.2. Mercurial will default to allowing TLS 1.1+ -
explicitly disallowing TLS 1.0. However, legacy versions of Python
don't support TLS 1.1+, so Mercurial will allow TLS 1.0+ rather than
prevent connections at all.
TLS 1.0 is borderline secure these days. I think it is a bug for TLS
1.0 to be used anywhere in the Firefox release process. This simple
patch changes our default Mercurial config in TaskCluster to require
TLS 1.2+ for all https:// communications. For modern Python versions,
this effectively prevents potential downgrade attacks to TLS 1.1
(connections before should have negotiated the use of TLS 1.2).
I expect this change to break things. Finding and fixing automation
that isn't capable of speaking TLS 1.1+ should be encouraged.
MozReview-Commit-ID: 876YpL5vB3T
--HG--
extra : rebase_source : 69c33c195f736a98b67d771e7364b6db28900ff4
Automation is now largely using Mercurial 4.1 with some lagging
components still on 3.9 and a very small sliver of random parts
still on 3.7.3. Let's update the mozharness tests to match what
automation is using.
FWIW, the Mercurial tests still pass on 3.9.
MozReview-Commit-ID: BgZVDcx29mf
--HG--
extra : rebase_source : edb8516491fe9ef616b1ad797be2fc02a89c2829
This is a pretty straightforward change. Just bumping package versions
and hashes. Behavior should be almost identical to the previous 4.1.1+
packages.
MozReview-Commit-ID: CaVjM0JHYKi
--HG--
extra : rebase_source : dcd0ee2661fd088daf3b5c6709c4c6f2f95bd410
Use "MOZ_LOG", which reminds people that mozlog is available.
MozReview-Commit-ID: 3h6ARVEUVhT
--HG--
extra : rebase_source : 816e50af750454f458628b4401646f0378b43246
The TASKCLUSTER_WORKER_GROUP environment variable used to contain the full
AWS availability zone, but a recent docker-worker change changed it to
be simply the AWS region, which broke sccache in taskcluster because we
were using it as part of the S3 bucket name.
MozReview-Commit-ID: 1KsfWpB4PoY
--HG--
extra : rebase_source : bdc61f180bf079eb0ad2cdbbd25e3e3a0deb62e6
The latest upstream version produces .dmg files that have fsck errors,
and some versions of OSX complain that the image is corrupted. The
previous version of libdmg-hfsplus that we were using (1d72dd62a)
doesn't have fsck errors, but it also doesn't preserve file permissions.
Our fork is based on the older version and backports the file permission
commits.
MozReview-Commit-ID: Bjwy6MJ98Ud
--HG--
extra : rebase_source : 5ecb3a3bbe9d8fe655fda7c1ce615bac91dc26fb
Editors generally look for configurations at the top level of a project. For ESLint, they also look for the specific binary in node_modules before defaulting to the system binary. Whilst you can override the location, generally it doesn't work well when switching between projects.
The custom in-tree libraries make setup of a system ESLint more difficult as well.
Therefore to make it simple for developers to pick up the ESLint integrations with Editors, by moving the package.json and associated node_modules to the top-level directory.
MozReview-Commit-ID: 1pQpd7hTQ61
--HG--
rename : tools/lint/eslint/npm-shrinkwrap.json => npm-shrinkwrap.json
rename : tools/lint/eslint/package.json => package.json
extra : rebase_source : 9d69d791f86b5c55b1fcd5f6449f0ab84e56b05c
In short shouldn't call err.stack(), it's a property.
MozReview-Commit-ID: 2HpPgsdctTv
--HG--
extra : rebase_source : 1769c125b4d720991c810f5c9460b2161ecbc8a8
Docker-worker's `command` field is actually not required, as it will run a
docker image's default command when command is not specified.
MozReview-Commit-ID: I3vBHeixlxW
--HG--
extra : rebase_source : a5d02c3131dd6ffb307c37e827d58aa8686ccaf8
A few commits ago, we bumped up the default zstandard compression level
from 3 to 10 when we switched to multi-threaded compression. Even with
multiple threads, this was a bit slower.
For images that will be built once and read multiple times, it is
worthwhile to burn extra CPU once and produce a small image. However,
for other tasks where the number of reads is limited, it isn't
worth it to use this extra CPU. This commit uses the SCM level as
a proxy for "optimize for speed." If the task is associated with level
1 (a try push), we lower the compression level and optimize for
speed. Otherwise, we keep the higher compression level and
optimize for image size.
Credit goes to Jonas for this terrific idea.
MozReview-Commit-ID: Hui97KsZpgw
--HG--
extra : rebase_source : 5a98e554166b51b8caa62b38d82e91c7b9fcb7ab
Using --no-install-recommends prevents installation of unwanted
packages and helps reduce image bloat. Using it in image_builder
reduces the image size from ~212.5 MB to ~203.6 MB. Not the
biggest savings. But savings nonetheless.
I kept python-pip separate because using --no-install-recommends with
it fails to pull in setuptools, gcc, and other packages required for
building Python packages. Since these packages are only needed
for generating the Docker image, I didn't feel like teasing out
the actual dependencies. It takes a little longer to install
temporary packages and build the image. But the end result should
mostly be the same.
MozReview-Commit-ID: EVURGKFuWzb
--HG--
extra : rebase_source : e1f953079480c6d898569dc7e14dc97890d4f41e
The goal of this change is to switch to python-zstandard for Docker
image compression so we can employ multi-threaded compression. This will
cut down the wall time it takes to compress images, decreasing end-to-end
times.
In order to use python-zstandard, I needed to write a Python script
for doing the compression. Since I was writing a Python script, I
figured I'd move Docker image downloading to that script as well.
This way, the raw Docker image never hits disk: it is streamed straight
from Docker into a zstandard compressor and that output is written to
disk. For large images, this will eliminate a few gigabytes of disk
writes.
The one extra complication about this I don't care for is you need a
special Python package to teach the "requests" package how to download
from UNIX domain sockets.
MozReview-Commit-ID: EufaRzR6A4Y
--HG--
extra : rebase_source : 2143bfee729bdc075c3a87a1e607eff2f0c164d2
Update rust-build docker image source to v0.4.3. This includes
some recent to how verification and taskcluster work to maintain
working scripts, and some changes for the newer cargo-building-
cargo build system, which aren't sufficient for bootstrapping.
MozReview-Commit-ID: 4IdbKVvco8m
--HG--
extra : rebase_source : f3cd2b7e8429648072ac02df5e8d4659c675f2ae