The mozharness_test job was using the wrong artifact path for native-engine.
Native-engine also enforces that artifact directories exist, so include some
mkdir calls to keep it happy.
MozReview-Commit-ID: Evw34gzzLev
--HG--
extra : rebase_source : 6ecf21e7d3516b8995f73e027666b39df31b0256
This makes talos obey the `-w` try syntax flag.
MozReview-Commit-ID: 2v6X3ko2t9K
--HG--
extra : rebase_source : 6d155ae390a4e3afc6499e8cd2f6a7f5459b12b7
extra : source : 6a561e8a5c2619fa4809dab1d7a90898e551b599
It was previously renamed in the Dockerfile, and that's unnecssarily confusing
when looking for the file in hg.
MozReview-Commit-ID: 7bwD4cjk4Pj
--HG--
rename : taskcluster/scripts/tester/test-ubuntu.sh => taskcluster/scripts/tester/test-linux.sh
extra : rebase_source : f22cd0f69c21e92126cc90ea3a4355e5c3db4205
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
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
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
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
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
(For "Integrate and fully support OSX Signing in taskcluster")
Written as a mozharness script rather than using bare ./mach command because we need to download the upstream artifact
and because we need to download artifacts from tooltool to do the packing back into a .dmg. Future ideal would be to get
rid of the mozharness script and use JUST ./mach.
This is using the ./mach repackage code being created in Bug 1347576. Taking a signed tarball from a dmg supported with
Bug 1346015, and the taskgraph work to schedule this is in Bug 1318505.
MozReview-Commit-ID: rv9l285HKC
--HG--
extra : rebase_source : 054219511419b8bf44b1f57a8d834a12c13710e3
extra : intermediate-source : a52bc37e08efbf4d6c68cc0f4e2d4b76f79b192a
extra : source : 6ad7468a590f5a2779ffdc3713c1f6f74ce23731
This formats the marionette-harness python tests to be a regular |mach python-test| suite. Though
we add subsuite=marionette, this is just for automation purposes. The new preferred way to run the
marionette harness tests locally is:
./mach python-test testing/marionette
They will also run if running the full suite.
The mozbase packages.txt file modifies mozlog to use 'setup.py' instead of 'pth'. The reason for
this is that the marionette-harness tests use the pytest_mozlog pytest plugin for formatting
their results (converts pytest format into something resembling the standard tbpl logging format).
In order for this plugin to get picked up however, mozlog's setup.py file needs to be processed.
MozReview-Commit-ID: Ata99evHxbd
--HG--
extra : rebase_source : 22382e3d65ce8454a1682cfced0d03477762e8fe
This formats the marionette-harness python tests to be a regular |mach python-test| suite. Though
we add subsuite=marionette, this is just for automation purposes. The new preferred way to run the
marionette harness tests locally is:
./mach python-test testing/marionette
They will also run if running the full suite.
The mozbase packages.txt file modifies mozlog to use 'setup.py' instead of 'pth'. The reason for
this is that the marionette-harness tests use the pytest_mozlog pytest plugin for formatting
their results (converts pytest format into something resembling the standard tbpl logging format).
In order for this plugin to get picked up however, mozlog's setup.py file needs to be processed.
MozReview-Commit-ID: Ata99evHxbd
--HG--
extra : rebase_source : 16ed70edd38a53c3279d8632d7cba3df4d5216c3
This is a minor refactor that aims to always attempt to set up 'mach' after running the 'run-mozharness' script.
We put it in a 'finally' block so we'll even do this if the user presses Ctrl-C or there was an exception
in the test harness. Importantly, this will be set up regardless of whether the user chooses "Option 1" or
"Option 2" at the wizard prompt.
The reason for this change is mostly 'might as well'. If it can save some users confusion, then it is worthwhile.
MozReview-Commit-ID: Dx3rV17FOoJ
--HG--
extra : rebase_source : 7ef4900409c4b5167bc7a18b27a87f77958e8937
There's not a single well-maintained fork of libdmg-hfsplus, but there are
scattered forks with various fixes. The fork + branch I've chosen here
seems to have collected the most fixes, including a specific fix we need
for repacking DMG files on Linux:
5c92af354b
MozReview-Commit-ID: 3RB6gfgQmCA
--HG--
extra : rebase_source : 40d145852a3876a983f1de7cacbc5ce5e68062a8
CLOSED TREE
Backed out changeset 158233bce738 (bug 1197325)
Backed out changeset b5ac3fa0bbe7 (bug 1197325)
Backed out changeset 55a8ad127517 (bug 1197325)
Dustin J. Mitchell
Mike Hommey
Wes Kocher
Steve Fink
Jeremy Chen
Manish Goregaokar
Iris Hsiao
Sebastian Hengst
Ted Mielczarek
Mike Shal
Justin Wood
William Lachance
Andrew Halberstadt
Phil Ringnalda