Less fickle check for cache growth

[squaremo]

In CI, the test that checks whether building at a stable path works with the go build cache occasionally fails. The test checks the output of du (disk usage) before and after, and fails (when it fails) with the difference of a small number of blocks.

Since the test is to check whether new objects are added to the cache, it's not necessary to check the size. On the assumption that the change in block usage is incidental, this commit changes that test so it compares the (sorted, recursive) list of file names before and after. New files would indicate new objects being introduced, and the test will fail (and if the change to stable build paths is reverted, that's what happens).

[rquitales]

Just a general question here - does a (even small) change in block usage of cache files not indicate that cache growth is occurring? Would we expect it to grow by large amounts each iteration?

I believe the original issue is that cache is rebuilt every time when we do not have a stable path for reconciling our stacks. So our go build cache size (and number of files) would be expected to grow linearly the more times we reconcile. This updates the test to ensure that the number of files in the cache doesn't grow, ie relatively constant. We made the assumption that we could check cache growth using storage size as a measure, but minor differences in the cache file sizes after reconciles makes this comparison harder, so using distinct counts of files is a better metric.

[squaremo]

does a (even small) change in block usage of cache files not indicate that cache growth is occurring?

Ramon's answer is absolutely on point. I am not sure why there's a difference in block use. It's always a small number of blocks difference to an existing file. It happens routinely in CI, but not nearly as much when the tests are run locally. It would seem that the compiler is recompiling a file, without its cache key changing. But I care much less about individual cache entries changing a little than about new cache entries -- the latter would indicate that stable paths do not fix the problem, and anyway be orders of magnitude difference.