-
Notifications
You must be signed in to change notification settings - Fork 3.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactor code to simplify manifest items and their creation #15308
Refactor code to simplify manifest items and their creation #15308
Conversation
76598af
to
e3df0ca
Compare
bacbe50
to
f2ef420
Compare
So, despite this mostly being done as refactoring to do other work for #15137, this has made the single-test case ( |
f2ef420
to
81bf08f
Compare
ad6367e
to
ff239c7
Compare
Can't figure out why the |
7fc1c9c
to
ff641e4
Compare
The one remaining failure is in |
faface3
to
96ecc4c
Compare
Given @Hexcles mentioned memory consumption of manifest generation in #12874 (comment): On Linux/x86_64, on this branch, manifest generation from scratch consumes max 487MB, no-op regeneration 202MB.
|
That is definitely promising! I also tested the memory footprint of manifest before (~1.5G from scratch) and it is indeed a problem for folks running tests on VMs (or Taskcluster workers, from forks of this repo) with <=4G memory. We should also try to free the memory ASAP. How much memory does the manifest take when we are running the tests (without manifest generation)? I assume it'd take take less than generating the manifest, and if so, it'd be great to make sure the delta is freed when the generation is completed. |
And the commit I've just pushed here makes it go down to max 165MB and 187MB respectively (the delta I presume is caused by it loading the old manifest and therefore having that in memory too). But this does now mean we aren't holding on to any file beyond the point at which we're directly processing that file. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
THis looks great. Let me double check it doesn't break gecko before approving.
It seems like this broke gecko by calling git unconditionally https://treeherder.mozilla.org/#/jobs?repo=try&author=james%40hoppipolla.co.uk&collapsedPushes=420652&fromchange=551ebec95f9b6ad9b5ac3d8812ee04b61d9024c3&selectedJob=230362281 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Need to ensure that git
isn't required when updating with --work
.
That's fixed now. |
c60bb58
to
22a5eb0
Compare
This hasn't been used by anyone in several years, and trying to fix the tests as part of the work for web-platform-tests#13507 tends to suggest that the chunker is itself broken. It is, in many ways, the least useful chunker as it results in test execution order changing every time the test execution time metadata is updated, and this leads to further flakiness.
In various places we write tests under the assumption that SourceFile returns the applicable type, which it doesn't. Fix our tests to always return RefTestNode. This allows us to get rid of a try/except block that exists purely to handle this case which is unreachable without mocks.
2679ebd
to
9178dc8
Compare
@gsnedders I've been running a script to regenerate manifests for all tagged commits locally and compare with what can be downloaded from GitHub releases. Starting with merge_pr_15308 there are a lot that have an added slash at the beginning of paths. I'm not sure why that happened, was that ever the intended behavior before, during or after this change? |
@gsnedders using "dom/nodes/Document-doctype.html" as a test path that's been around since 2014, it looks like the leading slash was originally not there in the manifest and at some point was added. From which commit should it be there, when doing a full rebuild of the manifest? |
@foolip not sure; it shouldn't be there (and isn't today). |
@gsnedders alright, I'll work on the assumption that it should never have been there. So far it looks like it's there for some manifests created using an incremental update, but not if you recreate the manifest from scratch on the same commit. |
No description provided.