Mercurial's sparse checkout support allows "profile" files defining
what's in sparse checkouts to be defined in-tree. This convenient
feature means you simply need to point a client at a path inside the
repository and it dynamically resolves what files to include in the
checkout. As you update revisions, the "profile" pulls in updates
to the underlying file.
We introduce 2 sparse profiles: 1 for mach and another for taskgraph.
The goal of the "mach" profile is to provide enough files to run
`mach`. If you activate this profile and run `mach`, it runs without
error. But there are practically no commands available. So it isn't
terribly useful.
The "taskgraph" profile allows us to run `mach taskgraph`. This
profile demonstrates a sparse profile feature: including other
profiles. The "taskgraph" profile is thus a union of "mach" and
its own entries.
There is definitely some fat in these profiles. I didn't feel like
chasing the long tail and getting overly granular with the profiles.
If we want to optimize later, we can do that.
For reference:
Full checkout: ~234,000 files
mach: ~2,000 files
taskgraph: ~3,600 files
MozReview-Commit-ID: 7pALt0MwHfE
--HG--
extra : rebase_source : 1a4ba4b8a63c522dab2841e2c0019501476da2fe
`run-task` is taught a --sparse-profile argument to be passed down
to `hg robustcheckout` for the main source checkout. It does what
you expect: performs a sparse checkout using the named profile.
The Taskgraph YAML for run-task is taught a "sparse-profile"
property to define the sparse profile. When defined, --sparse-profile
will be passed down to `run-task` and the cache name will be updated
to reflect the use of sparse checkout.
Our cache checking transform is updated to audit for the use of
--sparse-profile without the corresponding "-sparse" cache name
variation.
The reason we need a distinct cache name for sparse is because
clients that aren't sparse aware will be unable to read checkouts
that are sparse. By forcing sparse and non-sparse into different
cache pools, we avoid compatibility issues.
In the ideal world, we probably support sparse profiles on all the
VCS checkouts that `run-task` supports (e.g. --tools-checkout).
Perfect is the enemy of done. All of this is defined in-tree and
it is easy enough to change atomically.
MozReview-Commit-ID: 79k7Vul0hHO
--HG--
extra : rebase_source : babe9b42e2796c2341bffc6ecfe829f4daff9e0f
Include "error:" so Treeherder log parser picks things up (hopefully).
Also, actually include cache path in string.
MozReview-Commit-ID: 8b8ou7TJYZs
--HG--
extra : rebase_source : 52b43dd18419a6a8cfb096a6bf4262852c7c0ccc
<!-- Please describe your changes on the following line: -->
Follow up from the WebGL redesign: https://github.com/servo/servo/pull/17891
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `__` with appropriate data: -->
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [ ] These changes fix #__ (github issue number if applicable).
<!-- Either: -->
- [x] There are tests for these changes OR
- [ ] These changes do not require tests because _____
<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
Source-Repo: https://github.com/servo/servo
Source-Revision: 4598ddb0bcf62aa2ec54d896a67eae20db4588c0
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : ae0f3f7bedbe4a6d2313cc3e0120a347b597d91c
This was a test case for bug 1379203 (Google Inbox issue), but to pass this test
also needs the fix in this series to cancel animations when changing
animation-name to 'none' in the specified CSS rule.
Actually the fix in this series also fixes the Google Inbox issue so that this
test can pass without the fix for the Google Inbox issue. But even so without
the fix for bug 1379203, the style data for the first div element in this test
is cached and the second div element uses the cached data.
MozReview-Commit-ID: GfKSDfTZef4
--HG--
extra : rebase_source : caad72ed69e4ebeec8b8cad25949ea69e3bb652e
In the case where values in CSS rules changed directly by CSSOM, the old
value in the CSS rule block is immediately replaced by the new one. So if
the element, which is applied to the CSS rule, has running animations, the
new value is used during cascading process in animation-only restyle. Thus
in a subsequent normal restyle, we can't tell whether the value in the CSS
rule has changed or not. As a result, transitions may not be triggered
(bug 1393323) and CSS animations may not be cancelled if the updated
animation-name is 'none' (this bug).
For the latter case of CSS animations where animation-name has been updated to
'none', this patch introduces a workaround whereby we trigger an update of
running animations whenever the traversal is triggered by changes to CSS rules
and we have existing CSS animations.
change-animation-name-to-none-in-rule.html fails without servo #18214, succeeds
with this patch. Other two tests succeed regardless of the PR.
MozReview-Commit-ID: BrZgTNk9w41
--HG--
extra : rebase_source : 7a55f54a0f94c8db02639f9d8c89f785b3a17a1b
And convert consumers to context managers because hglib requires that.
MozReview-Commit-ID: Ckf1yBYeUlm
--HG--
extra : rebase_source : e76b2690bd02bc6889dbe0f4524d61669ba82367
Because hglib spawns a persistent process, we introduce a context
manager for Repository. It no-ops by default. On HgRepository it
controls the lifetime of the persistent hg process.
A helper method for running an hg command via hglib has been added.
We can't transition existing methods to hglib because hglib
requires a context manager, which no consumer is using yet.
MozReview-Commit-ID: 8z0fcGFeAm5
--HG--
extra : rebase_source : 914322f3647fb29406a22203811ac8cc0ac82420
python-hglib is a Python client for Mercurial's command server. It
facilitates querying Mercurial efficiently (using a single process)
and without having to parse output in the common case.
Let's vendor it so we can make use of it for more advanced Mercurial
scenarios.
Content vendored from changeset 820d7c1e470a without modifications
(other than deleting unwanted files).
As part of vendoring, we add the package to the virtualenv and make
it available to mach.
MozReview-Commit-ID: F4KLbW1lAvk
--HG--
extra : rebase_source : 39321a880a13a0b0323a7217f538978b729e2afe
If configure has defined VCS binaries, we should use those.
MozReview-Commit-ID: DVnsSaJC8eN
--HG--
extra : rebase_source : 64e944841817e7fa0300bc6ed3bce3325e93781a
Some callers already have a build config object. Let's not
make them call a function that imports buildconfig.
MozReview-Commit-ID: J22HhyVma9y
--HG--
extra : rebase_source : fa013dc0d8f85d1767e5666107ea656a17d137a2
This moves URI creation from ParseMetaDataEntry into SetupPrediction
because ParseMetaDataEntry is called in way more circumstances than we
actually need the URI from. Even in those cases where we might use the
URI (but it's not guaranteed), we end up using the URI less often than
we create one. In case it wasn't clear, SetupPrediction is the only
thing called post-ParseMetaDataEntry that would require a parsed URI in
the first place.
SetupPrediction has the duplicated NS_NewURI calls to avoid creating
URIs for those calls to SetupPrediction that are no-ops.
MozReview-Commit-ID: HlhVj7p2uuk
--HG--
extra : rebase_source : 0349dc52225b6e93150947ea978f2ba7afa3e2f5
We would like to be able to see if a given hang in BHR occurred
under high CPU load, as this is an indication that the hang is
of less use to us, since it's likely that the external CPU use
is more responsible for it.
The way this works is fairly simple. We get the system CPU usage
on a scale from 0 to 1, and we get the current process's CPU
usage, also on a scale from 0 to 1, and we subtract the latter
from the former. We then compare this value to a threshold, which
is 1 - (1 / p), where p is the number of (virtual) cores on the
machine. This threshold might need to be tuned, so that we
require an entire physical core in order to not annotate the hang,
but for now it seemed the most reasonable line in the sand.
I should note that this considers CPU usage in child or parent
processes as external. While we are responsible for that CPU usage,
it still indicates that the stack we receive from BHR is of little
value to us, since the source of the actual hang is external to
that stack.
MozReview-Commit-ID: JkG53zq1MdY
--HG--
extra : rebase_source : 8ab1bddb8274a074547886ce027df2d7d2b35fe5
MozReview-Commit-ID: DdMQpUY1WcJ
<!-- Please describe your changes on the following line: -->
https://bugzilla.mozilla.org/show_bug.cgi?id=1387933https://reviewboard.mozilla.org/r/171308/
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `__` with appropriate data: -->
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [ ] These changes fix #__ (github issue number if applicable).
<!-- Either: -->
- [ ] There are tests for these changes OR
- [ ] These changes do not require tests because _____
<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
Source-Repo: https://github.com/servo/servo
Source-Revision: 1e0ebf1c1ac6b00a7503dacecfa395df7daed229
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 6e9552d2a1c9a930f1176750088d37d7f20b4581
This removes a trait object from the path of reporting a CSS error.
---
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [X] There are tests for these changes
Source-Repo: https://github.com/servo/servo
Source-Revision: d4ddec8d33dbdaa248ae45d7c8ff58cfca7d7a5e
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 2cba60dc31ad007b10425814f9aa46299a053366
This allows multiple browser toolboxes to be opened at once, assuming the host
profiles have different values for devtools.debugger.chrome-debugging-port
MozReview-Commit-ID: 1bzsZFww4Zv
--HG--
extra : rebase_source : a2f631bb9d67ce4eabb9e8b1a2c3c32a5b8fd574
/home/worker/workspace/build/src/mozglue/build/WindowsDllBlocklist.cpp:816:1: error: 'noreturn' function does return [-Werror]
MozReview-Commit-ID: SYgPDW0sMV
--HG--
extra : rebase_source : d932e84ff0729b1c5ccff6658ee81849eb27eef4
This also prints the last known query used in the commit message. This won't be accurate as
users can delete + enter multiple queries in a single session, but will give users a slightly
better idea of what was scheduled by glancing at the commit message.
MozReview-Commit-ID: 93FbEmMvd9t
--HG--
extra : rebase_source : fc09dd145a5e88e5bb77e4e483552b579e90f3ca
Since these tests harnesses are already disabling Safe Browsing and tracking
protection, they should also disable the other two features that cause
lists to be downloaded from the Mozilla shavar server.
MozReview-Commit-ID: 2158qRU4XZx
--HG--
extra : rebase_source : 287bfb7580538cca7f58ab035b7141166346c318
Gregory Szorc
Imanol Fernandez
gasolin
Wes Kocher
Julian Descottes
Shane Caraveo
Hiroyuki Ikezoe
Dan Banner
Luke Chang
Brad Werth
Andrew Halberstadt
Nicholas Hurley
Markus Stange
Doug Thayer
Josh Matthews
Drew Willcoxon
Delphine Lebédel
Marina Samuel
Jared Wein
Jim Porter
Brian Grinstead
Tom Ritter
Andy McKay
Mike Conley
Francois Marier