Instead of over-estimating the number of items in a batch, do the opposite:
slightly under-estimate the number of items, then dispatch outstanding items
(by just adding one item to each batch).
Differential Revision: https://phabricator.services.mozilla.com/D23141
--HG--
extra : moz-landing-system : lando
Parts of this patch were taken from the original work of :bbouvier in Bug 1521772.
We needed to revert Bug 1521772 since it broken Windows compatibility.
Differential Revision: https://phabricator.services.mozilla.com/D23100
--HG--
extra : moz-landing-system : lando
It's occasionally useful to know what versions are being discovered for
these variables. It's also convenient for logs from automation to
contain all the relevant information, rather than setting up a loaner
and running all the commands yourself.
Differential Revision: https://phabricator.services.mozilla.com/D22385
--HG--
extra : moz-landing-system : lando
The jar log is used for optimization of the packaged jar files according
to their usage patterns during a profile run. The current content of the
file currently come with 2 caveats:
- it contains entries for jar archives that aren't relevant to
packaging, which is not a problem in itself, but see below.
- it contains full paths for jar archives that may not correspond to the
location of the packaged directory (on e.g. Android, where the build
almost certainly doesn't happen in the same directory on the host as
Fennec runs in the emulator/on the device).
The current JarLog code does somehow handle the various ways paths are
currently presented, but it's clearly missing code to map the paths in
the log to packaged paths. Instead of requiring manual work and extra
build options to handle this mapping, and considering the caveats above,
it's just simpler to log archive paths as if they were relative to the
packaged application directory in a build, and use that during
packaging.
Depends on D21655
Differential Revision: https://phabricator.services.mozilla.com/D21656
--HG--
extra : moz-landing-system : lando
The jar log is used for optimization of the packaged jar files according
to their usage patterns during a profile run. The current content of the
file currently come with 2 caveats:
- it contains entries for jar archives that aren't relevant to
packaging, which is not a problem in itself, but see below.
- it contains full paths for jar archives that may not correspond to the
location of the packaged directory (on e.g. Android, where the build
almost certainly doesn't happen in the same directory on the host as
Fennec runs in the emulator/on the device).
The current JarLog code does somehow handle the various ways paths are
currently presented, but it's clearly missing code to map the paths in
the log to packaged paths. Instead of requiring manual work and extra
build options to handle this mapping, and considering the caveats above,
it's just simpler to log archive paths as if they were relative to the
packaged application directory in a build, and use that during
packaging.
Depends on D21655
Differential Revision: https://phabricator.services.mozilla.com/D21656
--HG--
extra : moz-landing-system : lando
Before this change linting python/mozbuild brought about many errors. Some of this errors could be fixed using |mach lint --fix|. The remaining errors where fixed in this bug.
Differential Revision: https://phabricator.services.mozilla.com/D20138
--HG--
extra : rebase_source : 8bd3d622d2221b981f08b8a080c1198b002cdc49
extra : amend_source : 3f6a70c1b7104a7c2d83e11fe911942771e331ea
Fennec has a value of OMNIJAR_NAME that contains a directory, contrary
to other platforms, and relies in post-packaging, pre-unpacking steps to
accommodate with the difference.
With this change, we just make the packaging and unpacking steps aware
of this setup, and make allow them to pack/unpack resources in foo/
under foo/$OMNIJAR_NAME, whether $OMNIJAR_NAME is a file name or a path.
This will, further down the road, allow the packager code to handle jar
logs from PGO instrumentation without munging them.
Differential Revision: https://phabricator.services.mozilla.com/D21654
--HG--
extra : moz-landing-system : lando
The underlying backends only support directories in LOCAL_INCLUDES
(since these ultimately translate to -I arguments to the compiler). We
should disallow filenames here, in case a developer accidentally
specifies a header file instead of a directory.
Differential Revision: https://phabricator.services.mozilla.com/D21698
--HG--
extra : moz-landing-system : lando
In cases like those in the added unit test, explicit options on the
command line could end up being silently ignored. So instead of that happening,
error out. Unfortunately, the error message is not entirely accurate,
but it's better than nothing. It's rare anyways (I only stumbled upon it
because I was trying to do something fishy), and correlation between the
error message and the corresponding changes should make it clear what's
going on.
Depends on D20822
Differential Revision: https://phabricator.services.mozilla.com/D20823
--HG--
extra : moz-landing-system : lando
Currently, when a dependency loop involve imply_option, it is possible
to end up with an error message saying the implied option is unknown,
when it fact it is. So instead of bailing out with a weird error
message, try to make things work (if the implied value is not different
from what's known), or bail with a more accurate message.
Differential Revision: https://phabricator.services.mozilla.com/D20822
--HG--
extra : moz-landing-system : lando
Optimizing jars without preloading/reordering data only moves the
jar central directory to the beginning of the file, which, without
preloading information, is not very useful. Let's just stop doing it if
there's not going to be preloading/reordering information at all.
Differential Revision: https://phabricator.services.mozilla.com/D21170
--HG--
extra : moz-landing-system : lando
On Android we apparently try to include the cpufeatures.c file from the
NDK as part of the generated-sources tarball. While this works, it makes
tar drop the bogus entry for safety reasons when unpacking the archive.
It also makes tar return an error, which is undesirable for searchfox.
It's better to just skip the entry when building the tarball.
Differential Revision: https://phabricator.services.mozilla.com/D20942
--HG--
extra : moz-landing-system : lando
This patch adds detection for when icecream is in use to build telemetry.
icecream is commonly enabled in two ways: by either setting CC/CXX to point
to icecream's cc/c++ symlinks, or by setting adding
mk_add_options 'export CCACHE_PREFIX=icecc' to a mozconfig when also using
ccache. For the former, this patch adds a simple configure check to see
if CXX is a symlink to a file named 'icecc'. For the latter this patch adds
CCACHE_PREFIX as a configure subst to capture the value.
We don't currently have a facility for writing telemetry tests that depend on
configure values. Local manual testing shows that it does work as expected.
Differential Revision: https://phabricator.services.mozilla.com/D18138
--HG--
extra : moz-landing-system : lando
Instead of having cache misses for all variables that may vary when
getting job details. While the currently used variables are mostly
constants, we're going to introduce some flexibility in an subsequent
change.
Depends on D20443
Differential Revision: https://phabricator.services.mozilla.com/D20444
--HG--
extra : moz-landing-system : lando
Once all tests regexp are gone, we come to realize that all the package
regexp are the same for each ArtifactJob subclass, some we move the
definitions to the subclasses.
Depends on D20442
Differential Revision: https://phabricator.services.mozilla.com/D20443
--HG--
extra : moz-landing-system : lando
Once the firefox-* and fennec-* regexp are gone, we come to realize
that all jobs have the same regexp for tests, so we can just
use that across the board and remove the definition from JOB_DETAILS.
Depends on D20441
Differential Revision: https://phabricator.services.mozilla.com/D20442
--HG--
extra : moz-landing-system : lando
The filters were added back when buildbot was still used, and some
artifacts were still using file names beginning with "firefox" or
"fennec".
That is not true now that all builds are on taskcluster, and for all of
them, they are now target.$ext.
Differential Revision: https://phabricator.services.mozilla.com/D20441
--HG--
extra : moz-landing-system : lando
On CI, Windows builds start from different directories on every build,
except when sccache is enabled. This affects many build types, such as
l10n repacks, and the preprocessor likes to put full paths in its
output, which means it includes those different directories, making the
builds non reproducible.
This changes the preprocessor to replace the source and object
directories with generic strings.
Differential Revision: https://phabricator.services.mozilla.com/D20421
--HG--
extra : moz-landing-system : lando
This will avoid trying to generate them during artifact builds.
Depends on D20587
Differential Revision: https://phabricator.services.mozilla.com/D20436
--HG--
extra : moz-landing-system : lando
In bug 1522354, we changed host and target detection to not invoke
config.sub, assuming the output from config.guess would satisfy our
needs in split_target.
It turns out that on some plaforms, that doesn't work out, so, while we
still skip config.sub, we now catch errors from split_target when doing
so, and try again after running config.sub when split_target fails.
Differential Revision: https://phabricator.services.mozilla.com/D19937
Since bug 1522788, mach invokes a part of configure as part of getting
mozconfig and target information for its own purpose. The problem is
that the sandboxed code may sys.exit(), which then makes mach silently
exit.
So when the sandboxed configure code does sys.exit(), instead of
silently failing, we catch the exit call, and print out what we
captured.
Differential Revision: https://phabricator.services.mozilla.com/D19936
Currently, artifact builds pull from some task they determine from the
job type, and finding a pushhead.
Sometimes that latter fails, most notably on automation. But automation
can already know the right task to use without guesswork.
This change allows artifact builds to pull from a specific taskid given
through an environment variable, and make tasks from the artifact-build
kind (not the --artifact builds from try) use that.
Remove the workaround from bug 1382982 because it's now dead code.
Differential Revision: https://phabricator.services.mozilla.com/D19881
Turns out hg diff works differently, and when Miko tried to use this
option last week he realized it didn't work quite as expected.
Differential Revision: https://phabricator.services.mozilla.com/D20102
--HG--
extra : moz-landing-system : lando
Consequently, this removes:
- MOZ_LIBPRIO, which is now always enabled.
- non_msvc_compiler, which is now always true.
- The cl.py wrapper, since it's not used anymore.
- CL_INCLUDES_PREFIX, which was only used for the cl.py wrapper.
- NONASCII, which was only there to ensure CL_INCLUDES_PREFIX still
worked in non-ASCII cases.
This however keeps a large part of detecting and configuring for MSVC,
because we still do need it for at least headers, libraries, and midl.
Depends on D19614
Differential Revision: https://phabricator.services.mozilla.com/D19615
--HG--
extra : moz-landing-system : lando
