The psutil extension gets built on windows build machines during configure,
but that step only runs consistently after a clobber. This patch installs
psutil from a wheel in the mozharness virtualenv so it's available in
mozharness independent of what happens in the build.
--HG--
extra : commitid : EgDikk2zgod
This adds "basic" build time metrics to data already submitted to perfherder
from mozharness: the overall build time, and the duration of each build step
as a subtest.
--HG--
extra : commitid : FBjFaDzGeFc
OTA builds is publishing FOTA updates (and I don't have a context why)
so let's disable automatic balrog publshing and do it manually.
--HG--
extra : commitid : BArLZcu5neY
There are now Buildbot jobs which can be triggered via the Buildbot Bridge.
Buildbot test jobs triggered by BBB builds do not receive the installer and test
urls with a sendchange, hence, failling to run.
In order to pass the installer and test urls to Buildbot test jobs triggered
via BBB (which run with --read-buildbot-configs) we have added functionality
to find these build artifacts by querying TaskCluster.
Up until last quarter this worked because the Buildbot Bridge uploaded a proprties.json
file for every task it created to mirror a Buildbot job (bug 1221091).
Since that is broken, I have found that we can generate a buildbot_properties.json
file and upload it. The current upload mechanism for Buildbot build jobs is that
it creates a TC task and uploads the artifacts there. In this code change, we
determine when a Buildbot job is being driven by a task on TC (aka BBB) and tell
the upload system to use that task instead of creating a new one.
By doing that, tools like Mozilla CI tools can schedule TC graphs out of band by
specifying 'parent_task_id' and getting to the buildbot_properties.json file uploaded
by the parent build job.
--HG--
extra : commitid : 20XrR5whTms
extra : histedit_source : 2f41ffcd33ea7bb0a1fca1c95f92a2c4218b803e%2C7806527c93fc234daf87fa2c704138d4cd368cca
This will probably come back in the form of S3 uploads at some point.
--HG--
extra : rebase_source : b53c48dd26b093175f80562e84b367b4d00ea558
extra : histedit_source : 1ee2ff9bb4c88d0f4973a00ae93b6872a6252432
The Flame device updates have been broken for a while because of updates
starting to be too big. Because of the way applying OTA works, there is
no good solution except switching to applying Gecko/Gaia updates in
recovery mode. This was done in bug 1037056 on the Buildbot instances,
but we need to support this on TaskCluster also.
Foxfood devices are Sony Xperia Z3c devices. We need to be able to push
updates of the Gonk layer to fix some bugs. Those requires changes to
the kernel, to boot partition and to some other assets. Hence we add
support for producing all kind of updates packages we might need on that
device:
- ota, to update just Gecko/Gaia
- fota, to update Gecko/Gaia in recovery mode
- fota:fullimg, to be able to update gonk also
B2G updates can be of multiple types:
- OTA, applied without rebooting the device,
- FOTA with only Gecko/Gaia,
- FOTA with whole system partition files,
- FOTA dumping partitions images.
Each type of updates has its advantages and drawbacks. There is an
extensive documentation maintained on MDN about each and the options:
https://developer.mozilla.org/en-US/Firefox_OS/Building_and_installing_Firefox_OS/Firefox_OS_update_packages
All those updates are being packaged as a MAR file that gets injected
into the classical Firefox update mechanism, submitted to Balrog and
downloaded by the client. The content of the MAR will however depend on
the type of update: an OTA update will packate a Gecko and Gaia set of
files to update those parts; while any FOTA package is just an
update.zip that will get applied in recovery mode on the device.
So one fundamental difference is that OTA will not reboot your device
(just Gecko) while FOTA requires a working recovery mode and will reboot
your device. But OTA needs more system partition space to get applied,
and it can only update files that are within the /system/b2g/ directory.
FOTA on the other hand can update anything since the payload will
contain an update script written in Edify (Android recovery update
scripting language).
For each device we might need to produce several types of updates that
will be pushed to users depending on the context: for some users we want
to push just a Gecko/Gaia update, for some we know that we need to
update more content and thus we need to send some partitions.
Previously, the b2g_build.py script would only allow one kind of update
payload to be produced for each device available: we would need to have
a device "flame-kk-ota" and "flame-kk-fota" just to produce the OTA and
FOTA packages for the same device, thus resulting in a waste of
computing power and storage.
This commit introduces a new field "update_types" that can take an array
of values:
- ota, to produce an OTA package as before
- fota, to produce a FOTA package with only Gecko/Gaia
- fota:full, to produce a FOTA package of all files of the system
partition
- fota:fullimg, to produce a FOTA package dumping partitions
The old "update_type" will be used in the absence of "update_types". And
if none are present, we will keep defaulting to generating OTA as
previously.
This adds test configs for desktop linux64 unittests, including: mochitest-plain,
mochitest-browser-chrome, mochitest-devtools-chrome, reftest and xpcshell. It
also does a minor refactor of the b2g configs to remove some b2g-specific logic
from the base 'test.yml' config.
This does *not* schedule these tests anywhere just yet.
--HG--
extra : commitid : HdWat17LZNb
extra : rebase_source : 456b0261fc06131e22d8d5a37adf12f090abe5bd
