We're about to make MOZ_AUTOMATION more strict about things like having
a source checkout.
The whole point of build-sm-package.sh is to verify that SpiderMonkey
can be built outside of Mozilla's source repo and automation from a
standalone package. Since the presence of MOZ_AUTOMATION can influence
so much behavior in the build system, unset it so that the job
tests a !Mozilla environment more accurately.
MozReview-Commit-ID: EMfyLKfY0uU
--HG--
extra : rebase_source : 3632a9abf9fac3f916ed9043f30d4b6aa4abb390
The scripts that use tooltool-download.sh don't run regularly, but when
they do, they might hit some download problems (the relengapi proxy
tends to be rather unreliable for some reason), and in that case, it
would be better to retry a few times, like other job types, rather than
fail directly.
--HG--
extra : rebase_source : d85797f8eebff9be5b8bfc45fc14dfaf8d5a59f3
All the current users of tooltool-download.sh set $WORKSPACE. This will
allow to reuse the script on different types of workers, that don't have
$WORKSPACE set to $HOME/workspace, but still have the source in
$WORKSPACE/build/src.
--HG--
extra : rebase_source : c91542da70109e5708a009542a0f588e30b541a9
Using /home/worker is the build directory has a 30% talos performance
loss, because test machines has a /home mount directory.
MozReview-Commit-ID: zehcGJrUQX
--HG--
extra : source : feedcde68c2a54da210f03eb287ab5c862fc982b
extra : intermediate-source : 485d1af7805ad9fa0e701c3571fc1291fbfc6850
The toolchain build scripts are currently defining the tooltool
manifest they use on their own. We move the definitions to the
taskcluster job definitions to normalize on everything using that.
--HG--
extra : rebase_source : cbab2e32d78d711fcb595763d0c2600c7c0c423e
Hazard jobs use a specific tooltool-manifest field in their definition.
Since there is no post-processing happening on those definitions, and
since generalizing it would require adding the field to a bunch of
validation schemas, and the same code to various transforms, it's just
simpler to move to use environment variable definitions here too.
Eventually, tooltool manifests won't be necessary anyways, and those
environment variables will go away.
--HG--
extra : rebase_source : bd619024bde051424a2d811a1996caaf0f853247
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
Ryan VanderMeulen
Gregory Szorc
Mike Hommey
Wes Kocher
Wander Lairson Costa
Manish Goregaokar
Dustin J. Mitchell
Steve Fink
Jeremy Chen
Iris Hsiao
Sebastian Hengst
Ted Mielczarek
Mike Shal
Justin Wood
William Lachance
Andrew Halberstadt