You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jmeter.apache.org by Felix Schumacher <fe...@internetallee.de> on 2019/07/16 19:25:05 UTC
JMeter Windows Jenkins builds
Hi all,
lately I discovered, that we missed to convert the Windows Jenkins jobs
to use git. After I changed that, we now have a different problem.
The build fails (amongst other things) at checkstyle. I believe it is an
lf vs. crlf problem. I haven't found a setting to influence the
lineending checkout of the jenkins git plugin.
Maybe someone more knowledgeable wants to take a look at it?
Felix
Re: JMeter Windows Jenkins builds
Posted by Vladimir Sitnikov <si...@gmail.com>.
>I will try to make the test more tolerant against line ending
differences. It is about character encoding, not line endings ;)
Great, thanks. I'm glad to hear JMeter sources have no major CRLF issues :)
Vladimir
Re: JMeter Windows Jenkins builds
Posted by Felix Schumacher <fe...@internetallee.de>.
Am 17.07.19 um 16:16 schrieb Vladimir Sitnikov:
> Felix>Updated to 8.22. checkstyle is working again.
>
> Nice.
>
> Felix>We still have three tests failing. At least one is because of line
> endings:
>
> We have at least two approaches then:
>
> a) Wait for "https://issues.apache.org/jira/browse/INFRA-18763 to make
> Windows build hosts to use autocrlf=true"
> b) Update the test code so it tolerates the setting of
> "core.autocrlf=input" (== LF files in Windows).
>
> Note: the issue is not very Git-specific.
> For instance, if someone downloads apache-jmeter-*-source.tgz archive
> under Windows, then it would result in exactly the same failure.
>
> In other words, current
> test org.apache.jmeter.protocol.jms.sampler.render.ObjectMessageRendererTest#getValueFromFile_withDefaultEncodingAndProlog
> expects platform-specific line endings. However it is probably better to
> just normalize CRLF to LF before comparison, so the test would tolerate
> both styles of the etalon file.
> What do you think?
I will try to make the test more tolerant against line ending
differences. It is about character encoding, not line endings ;)
And as you noted, it will help in more cases.
Felix
PS I hope to find time to look at the gradle work when the build is
running again.
>
> Vladimir
>
Re: JMeter Windows Jenkins builds
Posted by Vladimir Sitnikov <si...@gmail.com>.
Felix>Updated to 8.22. checkstyle is working again.
Nice.
Felix>We still have three tests failing. At least one is because of line
endings:
We have at least two approaches then:
a) Wait for "https://issues.apache.org/jira/browse/INFRA-18763 to make
Windows build hosts to use autocrlf=true"
b) Update the test code so it tolerates the setting of
"core.autocrlf=input" (== LF files in Windows).
Note: the issue is not very Git-specific.
For instance, if someone downloads apache-jmeter-*-source.tgz archive
under Windows, then it would result in exactly the same failure.
In other words, current
test org.apache.jmeter.protocol.jms.sampler.render.ObjectMessageRendererTest#getValueFromFile_withDefaultEncodingAndProlog
expects platform-specific line endings. However it is probably better to
just normalize CRLF to LF before comparison, so the test would tolerate
both styles of the etalon file.
What do you think?
Vladimir
Re: JMeter Windows Jenkins builds
Posted by Felix Schumacher <fe...@internetallee.de>.
Am 17.07.19 um 09:36 schrieb Vladimir Sitnikov:
> Just in case, lf_cr_crlf is used by default since checkstyle-8.21:
> https://github.com/checkstyle/checkstyle/commit/d2a53a9818b46cc188b8a17cf6e7e9d19038db67
>
> So a mere upgrade of checkstyle version would help.
>
> Felix, would you please try that?
Updated to 8.22. checkstyle is working again.
We still have three tests failing. At least one is because of line endings:
[java] 3) getValueFromFile_withDefaultEncodingAndProlog(org.apache.jmeter.protocol.jms.sampler.render.ObjectMessageRendererTest)
[java] org.junit.ComparisonFailure: cache expected:<...ing="Windows-1252"?>[
[java] ]<org.apache.jmeter....> but was:<...ing="Windows-1252"?>[]
[java] <org.apache.jmeter....>
[java] at org.junit.Assert.assertEquals(Assert.java:115)
[java] at org.apache.jmeter.protocol.jms.sampler.render.ObjectMessageRendererTest.getValueFromFile_withDefaultEncodingAndProlog(ObjectMessageRendererTest.java:85)
[java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[java] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
[java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[java] at java.lang.reflect.Method.invoke(Method.java:498)
[java] at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
Felix
>
> Vladimir
>
Re: JMeter Windows Jenkins builds
Posted by Vladimir Sitnikov <si...@gmail.com>.
Just in case, lf_cr_crlf is used by default since checkstyle-8.21:
https://github.com/checkstyle/checkstyle/commit/d2a53a9818b46cc188b8a17cf6e7e9d19038db67
So a mere upgrade of checkstyle version would help.
Felix, would you please try that?
Vladimir
Re: JMeter Windows Jenkins builds
Posted by Vladimir Sitnikov <si...@gmail.com>.
Just in case,
A) I have created https://issues.apache.org/jira/browse/INFRA-18763 to make
Windows build hosts to use autocrlf=true.
B) It turns out Checkstyle has an option lineSeparator=lf_cr_crlf which
would make it tolerant to whatever line endings are used.
I guess we might want to add it to our Checkstyle configuration (see
https://checkstyle.sourceforge.io/apidocs/com/puppycrawl/tools/checkstyle/checks/NewlineAtEndOfFileCheck.html
)
Vladimir
Re: JMeter Windows Jenkins builds
Posted by Vladimir Sitnikov <si...@gmail.com>.
Felix>Maybe someone more knowledgeable wants to take a look at it?
TL;DR: "windows" build host is configured that it prefers to have LF line
separators in text files (there's core.autocrlf=input configured for some
reason).
That setting was activated in
https://issues.apache.org/jira/browse/INFRA-18383 (25 May 2019) which is
just plain wrong.
Git adheres to that configuration and checks out text files as LF
Then Checkstyle runs NewlineAtEndOfFile which recognizes that
platform==Windows, so the check expects CRLF.
There are at least two ways to deal with that:
A) Ask INFRA to configure core.autocrlf=true for Windows machine (which is
typically recommended for Windows)
B) Ask NewlineAtEndOfFile to support both CRLF / LF end of lines at the
same time. In other words,
it would make sense if NewlineAtEndOfFile could tolerate both LF/CRLF with
no dependence on the current platform.
Currently the check can be configured with a single style of line ending
only.
Vladimir