-
Notifications
You must be signed in to change notification settings - Fork 72
Description
The way zigup's testing works is every test has both an input and output directory. Each test's output can be used as the input to another test, i.e.:
const _7 = tests.add(.{
.name = "test-7",
.argv = &.{"0.7.0"},
.check = .{ .expect_stdout_match = "" },
});
tests.addWithClean(.{
.name = "test-already-fetched-7",
.env = _7,
.argv = &.{ "fetch", "0.7.0" },
.check = .{ .expect_stderr_match = "already installed" },
});
In the above example, the first test runs zigup 0.7.0 which will fetch the 0.7.0 compiler, and then its output is used as the input (or env) in the second test. Note that no other test uses the output of the second test so it uses addWithClean which means after the test runs it will clean it's output directory to save on disk space. However, even with these disk saving steps, we're still running out of disk space.
Most tests will have 1 or more copies of the compiler which will be hundreds of megabytes and there are many tests, so it only takes having a few dozen tests left around for us to exceed the disk limit of a few dozen gigabytes.
A solution that comes to mind is whenever a test finishes, we should know whether or not it should be cleaned or if it will need to be used by another test. If it does need to be used by another test, instead of leaving it around like we do today, we could instead compress it. Another option that would take more effort but potentially save disk space and runtime due to compression would be to make a special tool that is able to take any test output directory and create a patch script that can generate that same output directory using the compiler archives.
Another solution that comes to mind is in most cases the tests don't really care if the actual compiler is there, just that it's directory exists. In those cases we could just not copy all the contents of the actual compiler.