简体   繁体   English

Jenkins 上的文件内容突然更改

[英]File Content Suddenly Changes On Jenkins

This problem is a real headache.这个问题真是让人头疼。 I have some code to extract a ZIP file which looks like this:我有一些代码可以提取 ZIP 文件,如下所示:

    public File read(InputStream input) throws IOException {
        try (final BufferedInputStream bufferedInputStream = new BufferedInputStream(input);
                final ZipInputStream inputStream = new ZipInputStream(bufferedInputStream);) {

            final File outputFolder = Files.createTempDirectory(null).toFile();

            ZipEntry entry;
            while ((entry = inputStream.getNextEntry()) != null) {
                final File outputFile = new File(outputFolder, entry.getName());
                extractEntry(inputStream, outputFile);
            }
            return outputFolder;
        }
    }

    private void extractEntry(InputStream is, File outputFile) throws IOException {
        try (FileOutputStream fos = new FileOutputStream(outputFile);) {

            final byte[] buf = new byte[this.bufferSize];

            int length;
            while ((length = is.read(buf, 0, buf.length)) >= 0) {
                fos.write(buf, 0, length);
            }
        }
    }

My tests for this class just compares the file content I put into the ZIP with the file above code extracts:我对此 class 的测试只是将我放入 ZIP 的文件内容与上述代码提取的文件进行比较:

Assert.assertArrayEquals(Files.readAllBytes(referenceFile), Files.readAllBytes(extractedFile)); 

Which should work in any case, right?在任何情况下哪个应该起作用,对吧? It does for me.它对我有用。 The length of the files is 973 bytes on my machine.在我的机器上文件的长度是 973 字节。

However when run on Jenkins the very same tests with fail with the following exception:但是,当在 Jenkins 上运行时,相同的测试失败,但出现以下异常:

java.lang.AssertionError: array lengths differed, expected.length=996 actual.length=973

The actual numbers are fix, so the expected length is suddenly higher.实际数字是固定的,所以预期的长度突然变高了。 I habe no idea how that could possibly happen.我不知道这怎么可能发生。 When I download the files, they certainly look identical, even in a byte by byte comparison.当我下载这些文件时,它们看起来肯定是一样的,即使是逐字节比较也是如此。

What is the problem?问题是什么?

I made sure both machines run Open JDK 11.0.2, so for once the Java version shouldn't be the problem.我确保两台机器都运行 Open JDK 11.0.2,因此 Java 版本不应该成为问题。

So I found the solution while putting the question together, but I'll leave the answer here for myself and anyone else with mysterious problems:所以我在把问题放在一起时找到了解决方案,但我会把答案留给我自己和其他有神秘问题的人:

It's Git.它是 Git。 It's always Git with this kind of problems.出现这种问题的总是 Git。 Why would it be something different than Git?为什么它与 Git 不同?

Sometimes and without warning, Git decides that your line breaks are not good enough, and changes them to something else.有时,在没有警告的情况下,Git 会认为您的换行符不够好,并将其更改为其他内容。 My guess is since the byte count went up it added "\r" before or after my line break of "\n".我的猜测是,由于字节数增加,它在我的“\n”换行符之前或之后添加了“\r”。 Guess Git lost interest when it came to the ZIP files, and only changed the reference files.猜猜 Git 对 ZIP 文件失去了兴趣,只更改了参考文件。

So when my code extracted the ZIPs, they had the original line breaks, but the reference files had the Git changed ones, so they weren't identical.因此,当我的代码提取 ZIP 时,它们具有原始换行符,但参考文件的 Git 已更改,因此它们并不相同。

And while you could probably make a case for "Git randomly adding line breaks is a good thing", I have no idea why Git doesn't add them to your local repository as well.虽然您可能会提出“Git 随机添加换行符是一件好事”的理由,但我不知道为什么 Git 也不会将它们添加到您的本地存储库中。 I'd found the source of the problem a lot sooner if just my copy and the Jenkins copy were identical.如果我的副本和 Jenkins 副本相同,我会很快找到问题的根源。

Note: I found the problem because I thought it was a weird coincidence that the 23 bytes appeared on the Jenkins, when my file had 23 lines.注意:我发现问题是因为我认为当我的文件有 23 行时,Jenkins 上出现 23 个字节是一个奇怪的巧合。 So if you have a similar problem, try checking for something like this.因此,如果您有类似的问题,请尝试检查类似的内容。

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM