Proxxy is only configured in buildbot land. Don't enable it in
TaskCluster.
Ideally, we'd only enable proxxy if we detect we're in a buildbot
environment. But the change in this commit is more conservative
and aligns with existing behavior.
MozReview-Commit-ID: HBCdQ6MkYGa
This leak checker may be triggering a shutdown leak on Windows,
doesn't work with e10s, and should not be needed now that ttaubert
fixed the ++DOMWINDOW leak detector to work.
The additional GCs and CCs this patch adds used to be run as part of
cc-analyzer.js, and are needed to avoid window leaks in tests.
MozReview-Commit-ID: IzZI6h2SCr2
Failing to find symbols in this case should be turned into a warning rather than dumping the traceback
since we're going to rely on mozcrash doing the right thing later on.
This will reduce unnecessary reporting of symbols not being available.
MozReview-Commit-ID: GXO01B7vzGV
The virtualenv is placed in the "work dir" by default. If we
clobber the "work dir" at the beginning of the job, the parent
directory of the virtualenv may not exist and virtualenv creation
will fail because we set cwd to the work dir.
Fix that by ensuring the work dir / cwd always exists when
creating the virtualenv.
MozReview-Commit-ID: FAZPP1Sm22k
When we initially implemented support for robustcheckout, we didn't
have the magic "%include" syntax in Dockerfiles. So we used tooltool
to download robustcheckout.py to the image.
Now that we have nice things, we can use the vendored robustcheckout.py
file.
As part of this, I realized we're inconsistently using /tmp, /setup
and /build for files used during image building. That should probably
be cleaned up. I'd rather not bloat scope for this bug, however.
MozReview-Commit-ID: D99Gcdw1DId
From changeset 3282813aa892f0fc247181a33ce0bde2b751da50 from the
version-control-tools repo. File added without modifications.
Upstream change was peer reviewed.
Failing to find symbols in this case should be turned into a warning rather than dumping the traceback
since we're going to rely on mozcrash doing the right thing later on.
This will reduce unnecessary reporting of symbols not being available.
MozReview-Commit-ID: GXO01B7vzGV
Check try message for --artifact even if fx_desktop_build.py is run with
--skip-buildbot-actions
We can't rely on buildbot config. Add checks to TryToolsMixin._extract_try_message so
that it works even if self.buildbot_config is None.
MozReview-Commit-ID: 1xErjuOArBe
These are the only 2 definitions of the hg.mozilla.org certificate
fingerprint in mozilla-central. The certificate changed on
2016-09-26. So update the fingerprints.
This /might/ be a cargo cult because automation should be pinning
the hg.mozilla.org certificate everywhere. An alternative to this
commit would be to remove the fingerprint pinning from these
scripts. But if these scripts are run by humans, we may want to keep
the pinning in.
MozReview-Commit-ID: 4FUhAGc2oqx
HSTS priming changes the order of mixed-content blocking and HSTS
upgrades, and adds a priming request to check if a mixed-content load is
accesible over HTTPS and the server supports upgrading via the
Strict-Transport-Security header.
Every call site that uses AsyncOpen2 passes through the mixed-content
blocker, and has a LoadInfo. If the mixed-content blocker marks the load as
needing HSTS priming, nsHttpChannel will build and send an HSTS priming
request on the same URI with the scheme upgraded to HTTPS. If the server
allows the upgrade, then channel performs an internal redirect to the HTTPS URI,
otherwise use the result of mixed-content blocker to allow or block the
load.
nsISiteSecurityService adds an optional boolean out parameter to
determine if the HSTS state is already cached for negative assertions.
If the host has been probed within the previous 24 hours, no HSTS
priming check will be sent.
MozReview-Commit-ID: ES1JruCtDdX
