I'm working on a software that builds Pacman packages (which basically are tarballs with some special metadata files). The test suite builds some packages, then compares the resulting package to a recorded expected result.
One of the fields in the metadata recorded in the package is the installed size of the package, determined by running
du -s --apparent-size on the root directory before tar'ing it.
All of this works perfectly fine on my local Arch Linux boxes where I develop. The packages, including their installed size in bytes (not even kilobytes, bytes!) is reproduced exactly every time I run the test.
Now I've also enabled this test on Travis, where it runs (as far as I understand from the Travis docs) on an Ubuntu-12.04-based container. There, the test passes most of the times. Most of the times. Sometimes, it calculates installed sizes that are off by 80-99%.
@@ -37,7 +37,7 @@ pkgdesc = my foo bar package url = packager = Unknown Packager - size = 37728 + size = 1464 arch = any license = custom:none replaces = foo-bar<2.1
The puzzling thing about this is that it only happens some of the time, with no apparent pattern. The test arranges the same files as it always does, runs
du -s --apparent-size on the resulting tree, and arrives at a completely wrong result. I have tried to reproduce this on a Ubuntu 12.04 VM, and while I have seen it appear there once or twice, I could not see any patterns emerge there either that would help me reproduce the problem.
Maybe someone here has an idea what could cause this issue?
EDIT: Oh, there is one pattern that I observed, actually.
du runs once for each testcase. When it fails for the first testcase, it will fail for all testcases in this run.