Not sure how it happened (probably copy-paste?) but a lot of Android jobs are
marked for "Android 4.0" (API 14) or "Android 4.2" (API 18) while really they
are all for Android 4.1 (API 16). This patch fixes that.
Differential Revision: https://phabricator.services.mozilla.com/D117050
Not sure how it happened (probably copy-paste?) but a lot of Android jobs are
marked for "Android 4.0" (API 14) or "Android 4.2" (API 18) while really they
are all for Android 4.1 (API 16). This patch fixes that.
Differential Revision: https://phabricator.services.mozilla.com/D117050
Not sure how it happened (probably copy-paste?) but a lot of Android jobs are
marked for "Android 4.0" (API 14) or "Android 4.2" (API 18) while really they
are all for Android 4.1 (API 16). This patch fixes that.
Differential Revision: https://phabricator.services.mozilla.com/D117050
This patch allows the desktop recorder to be run manually. A subsequent patch
will enable it for every m-c push once the hardware is deployed.
Differential Revision: https://phabricator.services.mozilla.com/D117367
CLOSED TREE
Backed out changeset d8f2f3cc4da7 (bug 1709640)
Backed out changeset 3a6a274dae0d (bug 1709640)
Backed out changeset decc4edd47f9 (bug 1709640)
Not sure how it happened (probably copy-paste?) but a lot of Android jobs are
marked for "Android 4.0" (API 14) or "Android 4.2" (API 18) while really they
are all for Android 4.1 (API 16). This patch fixes that.
Differential Revision: https://phabricator.services.mozilla.com/D117050
We don't offer API splits any more, and with the separation of GeckoView with
the rest of the front-end it's increasingly unlikely that we will in the
future.
This change makes it so that the build name doesn't contain the API version so
that we can update it without breaking all the automation that relies on the
build name.
Differential Revision: https://phabricator.services.mozilla.com/D114369
We don't offer API splits any more, and with the separation of GeckoView with
the rest of the front-end it's increasingly unlikely that we will in the
future.
This change makes it so that the build name doesn't contain the API version so
that we can update it without breaking all the automation that relies on the
build name.
Differential Revision: https://phabricator.services.mozilla.com/D114369
I have manually pinned the requirements, and partials are working. We'll lose a way to auto-update our dependencies, but a) it's perma-busted, so realistically we're just losing a busted task, and b) mhentges is working on a way to auto-update pinned dependencies in-tree.
Differential Revision: https://phabricator.services.mozilla.com/D110148
To identify regressions and existing exceptions in Sentry, we tag them
with their mach release (the current base revision).
To ensure that Sentry knows the correct order of revisions, we need to
tell it about each one that lands in mozilla-central.
Differential Revision: https://phabricator.services.mozilla.com/D109681
This implements a --diff flag on the suite of |mach taskgraph| commands. E.g:
./mach taskgraph target -p project=autoland -J --diff
The above will update to the base revision of your stack (e.g the public
revision), generate the taskgraph, update to the current revision, generate the
taskgraph again, then display a diff of the two.
You can also specify a specifier to arg, e.g:
./mach taskgraph target -J --diff .~1
This will diff against the parent revision in mercurial (use 'HEAD~1' for git).
Differential Revision: https://phabricator.services.mozilla.com/D107274
The mozjs_sys crate is actually responsible for all the problems
encountered with the js crate we just removed, but the sm-mozjs-crate
task that builds and runs tests for it doesn't fail because... there is
actually no test to build and run, so all it builds is a static library,
which doesn't expose all the problems that exist.
The content of this crate in mozilla-central is also outdated compared
to servo upstream.
Differential Revision: https://phabricator.services.mozilla.com/D106390
The sm-rust-bindings task that builds and runs tests for it actually only
doesn't fail by three(!) distinct happenstances of chance:
- It somehow doesn't hit a race condition that can happen, but that
attempting to change the build process for jsglue.cpp did,
- The second call to `cargo test` without `--feature debugmozjs` only
works because nothing was cleaned up from the first and the second
build uses artifacts from the first that are otherwise not there if
only running the second.
- The addition of rust code to spidermonkey (the jsrust crate in
js/src/rust) somehow didsn't cause problems in the current
configuration, but in other configurations (which fixing the second
thing above unveils) the build fails because of the multiple
definition of rust_eh_personality between the jsrust staticlib and the
rust stdlib that rustc links to test programs.
On top of all the above, the content of the crate in mozilla-central
has not received updates from upstream servo in years, and doesn't
reflect what servo actually uses.
Differential Revision: https://phabricator.services.mozilla.com/D106389
The links and instructions in the page have been updated to reflect the
changes in the symbol server and the old copy was removed. Images have been
recompressed to reduce size.
Differential Revision: https://phabricator.services.mozilla.com/D92878
We want to be able to retroactively tell whether a push was a backstop or not.
This patch stores whether or not a push was a "backstop" directly in the
parameters. The optimization strategy now simply returns 'not
params["backstop"]'.
For simplicity, I'm not counting the 'optimized-backstop' as a backstop. It's
unclear if we'll want to be able to detect these types of the pushes in the
future or not, but we can cross that bridge when we get there.
Differential Revision: https://phabricator.services.mozilla.com/D88151
Certain tasks are meant to perform follow-up work to another task. For example,
a 'signing' task signs an artifact from a dependency task. An 'upload-symbols'
tasks uploads an artifact from a dependency task.
In general, we only want to run these types of tasks when the dependency task
is running. But in practice, these tasks often cause the dependency to get
pulled in.
We've tried to fix this in the past by making the 'run-on-projects' and
'optimization' keys match their primary dependency. But it's very easy to
mess this up, and some optimizations (like bugbug) take the content of the
task definition into account. So even if both tasks use the same optimization,
they could have different results.
This revision adds a new 'if-dependencies' key that denotes a task that should
only run if one of the dependencies specified in this list is also run. It
will allow us to stop playing whack-a-mole when trying to make sure tasks
aren't being pulled in solely due to these types of dependencies.
This feature is implemented independently of the 'optimization', so tasks that
specify this can still be optimized even if their primary dependency does run.
Differential Revision: https://phabricator.services.mozilla.com/D80508
This is a fork of the release-partner-repack-beetmover kind and transform. It's modified to cope with having one upstream task with many partner builds, rather than a many beetmover tasks dealing with a single config-platform-locale combination.
Differential Revision: https://phabricator.services.mozilla.com/D87730
Agi Sferro
Sebastian Hengst
Butkovits Atila
Julien Cristau
Barret Rennie
Mike Hommey
Aki Sasaki
surajeet310
Brindusan Cristian
Agi Sferro
Sandor Molnar
Rob Lemley
Michelle Goossens
Mitchell Hentges
Andrew Halberstadt
Ben Hearsum
Tarek Ziadé
Johan Lorenzo
gsvelto
Sylvestre Ledru
Tom Ritter
Narcis Beleuzu
Mihai Tabara
Emil Farisan
Andrew Halberstadt
Nick Thomas