.dockerignore, Dockerfile: add a zig cache

[ee7]

Running the tests for a Zig exercise was much slower than it should be, because every test run was the first time that Zig was run in the image.

Let's try an initial simple approach: run zig test once (for tests/example-success) and copy the resulting zig cache into the Docker image. This seems like a 2.2x speedup when running a subsequent exercise test, at the cost of adding a 41 MB zig cache to the image:

33 MB  /root/.cache/zig/z/
 8 MB  /root/.cache/zig/o/
22 kB  /root/.cache/zig/h/

Edit: Later, I believe we can speedup further by caching the result of compiling more functions from std.testing.
The speedup was better with the hello-world files because we cached testing.expectEqualStrings. But let's add a different test file in a follow-up PR that uses a bunch of common functions.

Closes: #28

---

This is sufficient to produce a significant speedup locally (from about 5 seconds to 2.3 seconds). And I think it's sufficient to produce the same significant speedup in production, but I'm not certain. I think it's easiest to just measure the approximate duration of a test run from the online editor before merging, merge, and test again after deploying.

Instead of adding the hello-world files to this repo, we could fetch them from the track repo at build time. But I think I'd rather avoid the extra network request.

To-do:

• Rather than adding hello-world files, consider initializing the cache by testing an existing file in the tests directory

zig-test-runner/tests/example-success/example_success.zig

Lines 1 to 3 in 9d7c3f2

	pub fn leap(year: u32) bool {
	return year % 4 == 0 and (year % 100 != 0 or year % 400 == 0);
	}

[ErikSchierboom]

Very nice

[ee7]

I ran the tests for leap from the online editor 10 times, starting around 2023-08-23T10:20:00Z. The execution time mean and sample standard deviation: 11 ± 1 s.

Let's see if it improves after merging.

[ee7]

Starting at 2023-08-23T10:55:00Z (after the deployed test runner updated to 82b56af) I repeated the above test for the same exercise, and I got 14 ± 3 s.

Edit: same thing at 2023-08-23T11:20:00Z. And it seems the same for other exercises: I don't think it's a special case of only leap being slow, as a result of producing the compilation cache by running the tests for leap.

@ErikSchierboom do we already have a process for comparing an exercise's test execution time across two different test runner images? If so, can you reproduce the above slow down? I'm certain it's a large speedup for me locally. But if it seems to be legitmately worse in production, I'll revert the commit. I realize there's some noise in the measurement.

[ErikSchierboom]

do we already have a process for comparing an exercise's test execution time across two different test runner images

I'm afraid we don't, sorry.