Clean up emitted files as the test harness runs #4086
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #4082.
Overview
Currently, the test harness leaves behind the OBJ, EXE, etc. files that it builds. These are safely contained within the
out
subdirectory, and they're easily dealt with viagit clean
. However, this means that large test runs leave behind a lot of emitted files. After ASAN configurations were added to the matrix, I observed that a full test pass left behind ~200 GB of files on my local machine, causing my 1 TB SSD to run out of space. 🙀These emitted files are never useful to us. If we have to investigate a particular test, we always want to rebuild it by hand, and extracting the relevant command line from the logs is easy (for all except the header units test, and the emitted artifacts aren't any more helpful there). This is because the vast majority of our plain test configurations don't use
/Zi
(so if we want debug info we have to add it), and because we typically want to do something like hack a header and rebuild with an overlay/I
option while investigating a potential fix.How I developed this PR
I knew that our test harness created different subdirectories for different test configurations. While trying to find where this happened, I noticed that
format.py
was organized into comprehensible "steps", and it starts with a "build setup" step that deletes and recreates the test subdirectory:STL/tests/utils/stl/test/format.py
Lines 161 to 163 in f362f7d
Immediately above,
getStages()
was designed in a really nice way to return an array of stages. This was extensible, instead of having a specific sequence of stages hardcoded everywhere. So all I had to do was introduce a "Clean" stage at the end, performing the sameshutil.rmtree()
command that's run at the very beginning.The one thing to pay attention to is the bool at the end of each listed stage. This is
isBuildStep
, which is used to handle build-only configurations:STL/tests/utils/stl/test/format.py
Lines 220 to 222 in f362f7d
When
isBuildStep
isTrue
, the step is always run (which is what we want for this new Clean step).False
steps are for running tests, which are skipped for build-only configurations.How I tested this PR
After building the STL, I captured the
out\x64
directory contents before and after running a pair of tests (compile-only and runtime). (%STL%
is my repo root.)For
main
, the before-and-after difference displayed a bunch of emitted files. In addition to thetesting_x64.log
that I explicitly requested, LLVMlit
generated one file, and then each subdirectory contained a bunch. Trimmed my repo root for clarity:With this PR, only the explicitly requested log file and the LLVM
lit
generated file survive: