steps
./mill -w 'integration.feature[reproducibility].local.server' mill.integration.ReproducibilityTests.diff`
- Extract and decompress the
zinc analysis files via
cp out/integration/feature/reproducibility/local/server/test.dest/sandbox/run-1/out/mill-build/compile.dest/zinc zinc-1.txt.gz && cp out/integration/feature/reproducibility/local/server/test.dest/sandbox/run-2/out/mill-build/compile.dest/zinc zinc-2.txt.gz && gunzip zinc-2.txt.gz && gunzip zinc-1.txt.gz
problem
This results in two different files
Attached
zinc-1.txt
zinc-2.txt
It seems that this libraryClassName key in the zinc config picks a random class from each jar to store in the analysis file, and which class gets picked differs every time
expectation
I would expect the zinc files to contain the same contents every time. I already have custom ReadWriteMappers that successfully normalize all the file paths, but this class-based non-determinism doesn't seem related to any files
notes
It seems like libraryClassName should contain a list of every class available in each library, but somehow it's only containing a single class per library, presumably picked arbitrarily. Not sure if we're configuring zinc incorrectly or something
steps
zincanalysis files viaproblem
This results in two different files
Attached
zinc-1.txt
zinc-2.txt
It seems that this
libraryClassNamekey in the zinc config picks a random class from each jar to store in the analysis file, and which class gets picked differs every timeexpectation
I would expect the zinc files to contain the same contents every time. I already have custom
ReadWriteMappersthat successfully normalize all the file paths, but this class-based non-determinism doesn't seem related to any filesnotes
It seems like
libraryClassNameshould contain a list of every class available in each library, but somehow it's only containing a single class per library, presumably picked arbitrarily. Not sure if we're configuring zinc incorrectly or something