12377 ZnHTTPSTests.>>testGetPharoVersion fails on Windows slave https://pharo.fogbugz.com/f/cases/12377 And this is just a build server artefact⦠(windows slave firewall problem). I wonder what to do⦠maybe we could just skip it on windows when running on the build slave ;-) Marcus
On 08 Jan 2014, at 09:48, Marcus Denker <marcus.denker@inria.fr> wrote:
12377 ZnHTTPSTests.>>testGetPharoVersion fails on Windows slave https://pharo.fogbugz.com/f/cases/12377
And this is just a build server artefact⦠(windows slave firewall problem).
I wonder what to do⦠maybe we could just skip it on windows when running on the build slave ;-)
Marcus
Yes, either that (BTW, is it possible to know you are running on a slave ?) or some (Windows) sysadmin should have a look. Using any Pharo image the following should work and return XML: ./pharo Pharo.image eval "ZnClient new get: 'https://ci.inria.fr/pharo/job/Pharo-2.0/lastSuccessfulBuild/api/xml?xpath=/*/description\'.â But without the smart quote at the end (sorry, I canât make Mail not do that). Sven
On 08 Jan 2014, at 10:14, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 08 Jan 2014, at 09:48, Marcus Denker <marcus.denker@inria.fr> wrote:
12377 ZnHTTPSTests.>>testGetPharoVersion fails on Windows slave https://pharo.fogbugz.com/f/cases/12377
And this is just a build server artefact⦠(windows slave firewall problem).
I wonder what to do⦠maybe we could just skip it on windows when running on the build slave ;-)
Marcus
Yes, either that (BTW, is it possible to know you are running on a slave ?)
We could add a check for an environment variable that Jenkins sets.
or some (Windows) sysadmin should have a look.
Using any Pharo image the following should work and return XML:
./pharo Pharo.image eval "ZnClient new get: 'https://ci.inria.fr/pharo/job/Pharo-2.0/lastSuccessfulBuild/api/xml?xpath=/*/description\'.â
But without the smart quote at the end (sorry, I canât make Mail not do that).
I will check with the admins⦠Marcus
On 08 Jan 2014, at 10:17, Marcus Denker <marcus.denker@inria.fr> wrote:
On 08 Jan 2014, at 10:14, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 08 Jan 2014, at 09:48, Marcus Denker <marcus.denker@inria.fr> wrote:
12377 ZnHTTPSTests.>>testGetPharoVersion fails on Windows slave https://pharo.fogbugz.com/f/cases/12377
And this is just a build server artefact⦠(windows slave firewall problem).
I wonder what to do⦠maybe we could just skip it on windows when running on the build slave ;-)
Marcus
Yes, either that (BTW, is it possible to know you are running on a slave ?)
We could add a check for an environment variable that Jenkins sets.
And then access it with OSPlatform current environment right ? What environment variables are already set by Jenkins (on all platforms) ? Which one should we test for ?
or some (Windows) sysadmin should have a look.
Using any Pharo image the following should work and return XML:
./pharo Pharo.image eval "ZnClient new get: 'https://ci.inria.fr/pharo/job/Pharo-2.0/lastSuccessfulBuild/api/xml?xpath=/*/description\'.â
But without the smart quote at the end (sorry, I canât make Mail not do that).
I will check with the adminsâ¦
Marcus
On 08 Jan 2014, at 11:34, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 08 Jan 2014, at 10:17, Marcus Denker <marcus.denker@inria.fr> wrote:
On 08 Jan 2014, at 10:14, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 08 Jan 2014, at 09:48, Marcus Denker <marcus.denker@inria.fr> wrote:
12377 ZnHTTPSTests.>>testGetPharoVersion fails on Windows slave https://pharo.fogbugz.com/f/cases/12377
And this is just a build server artefact⦠(windows slave firewall problem).
I wonder what to do⦠maybe we could just skip it on windows when running on the build slave ;-)
Marcus
Yes, either that (BTW, is it possible to know you are running on a slave ?)
We could add a check for an environment variable that Jenkins sets.
And then access it with
OSPlatform current environment
right ?
What environment variables are already set by Jenkins (on all platforms) ? Which one should we test for ?
Right now we do not set any special one⦠but we could There is right now on all slaves: (here with values for win): OS = win Architecture = 32 TERM = xterm-color LC_ALL = en_US.UTF-8 We can add more⦠Marcus
On 08 Jan 2014, at 13:09, Marcus Denker <marcus.denker@inria.fr> wrote:
On 08 Jan 2014, at 11:34, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 08 Jan 2014, at 10:17, Marcus Denker <marcus.denker@inria.fr> wrote:
On 08 Jan 2014, at 10:14, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 08 Jan 2014, at 09:48, Marcus Denker <marcus.denker@inria.fr> wrote:
12377 ZnHTTPSTests.>>testGetPharoVersion fails on Windows slave https://pharo.fogbugz.com/f/cases/12377
And this is just a build server artefact⦠(windows slave firewall problem).
I wonder what to do⦠maybe we could just skip it on windows when running on the build slave ;-)
Marcus
Yes, either that (BTW, is it possible to know you are running on a slave ?)
We could add a check for an environment variable that Jenkins sets.
And then access it with
OSPlatform current environment
right ?
What environment variables are already set by Jenkins (on all platforms) ? Which one should we test for ?
Right now we do not set any special one⦠but we could
There is right now on all slaves: (here with values for win):
OS = win Architecture = 32 TERM = xterm-color LC_ALL = en_US.UTF-8
We can add moreâ¦
Well, it should be something like: JENKINS = ci.inria.fr Then the guard for the unit test could be (OSPlatform current environment at: #JENKINS ifAbsent: [ '' ]) = 'ci.inria.fr' ifTrue: [ ^ self ] to skip the test only on the INRIA CI servers. Maybe CI instead of JENKINS is a more general name.
Well, it should be something like:
JENKINS = ci.inria.fr
Then the guard for the unit test could be
(OSPlatform current environment at: #JENKINS ifAbsent: [ '' ]) = 'ci.inria.fr' ifTrue: [ ^ self ]
to skip the test only on the INRIA CI servers.
Maybe CI instead of JENKINS is a more general name.
Ok, I added CI = ci.inria.fr to the windows slaves
On 08 Jan 2014, at 13:37, Marcus Denker <marcus.denker@inria.fr> wrote:
Well, it should be something like:
JENKINS = ci.inria.fr
Then the guard for the unit test could be
(OSPlatform current environment at: #JENKINS ifAbsent: [ '' ]) = 'ci.inria.fr' ifTrue: [ ^ self ]
to skip the test only on the INRIA CI servers.
Maybe CI instead of JENKINS is a more general name.
Ok, I added
CI = ci.inria.fr
to the windows slaves
OK, let's do this then: == Name: Zinc-Zodiac-SvenVanCaekenberghe.28 Author: SvenVanCaekenberghe Time: 8 January 2014, 1:57:17.629973 pm UUID: 5c5d4ae3-5db1-4367-adfe-6341cda0fc41 Ancestors: Zinc-Zodiac-SvenVanCaekenberghe.27 Add a guard to ZnHTTPSTests>>#testGetPharoVersion to skip the whole test when #runningOnWindowsInriaCI === This is now in the upstream repositories, I will make a slice for https://pharo.fogbugz.com/f/cases/12377/ZnHTTPSTests-testGetPharoVersion-fai... Sven
There are multiple approaches to get green tests :) Am 08.01.2014 um 14:00 schrieb Sven Van Caekenberghe <sven@stfx.eu>:
Norbert
On 08 Jan 2014, at 13:37, Marcus Denker <marcus.denker@inria.fr> wrote:
Well, it should be something like:
JENKINS = ci.inria.fr
Then the guard for the unit test could be
(OSPlatform current environment at: #JENKINS ifAbsent: [ '' ]) = 'ci.inria.fr' ifTrue: [ ^ self ]
to skip the test only on the INRIA CI servers.
Maybe CI instead of JENKINS is a more general name.
Ok, I added
CI = ci.inria.fr
to the windows slaves
OK, let's do this then:
== Name: Zinc-Zodiac-SvenVanCaekenberghe.28 Author: SvenVanCaekenberghe Time: 8 January 2014, 1:57:17.629973 pm UUID: 5c5d4ae3-5db1-4367-adfe-6341cda0fc41 Ancestors: Zinc-Zodiac-SvenVanCaekenberghe.27
Add a guard to ZnHTTPSTests>>#testGetPharoVersion to skip the whole test when #runningOnWindowsInriaCI ===
This is now in the upstream repositories, I will make a slice for https://pharo.fogbugz.com/f/cases/12377/ZnHTTPSTests-testGetPharoVersion-fai...
Sven
Haha ;-) On 08 Jan 2014, at 14:52, Norbert Hartl <norbert@hartl.name> wrote:
There are multiple approaches to get green tests :)
Am 08.01.2014 um 14:00 schrieb Sven Van Caekenberghe <sven@stfx.eu>:
<Bildschirmfoto 2013-09-27 um 11.49.40.png>
Norbert
On 08 Jan 2014, at 13:37, Marcus Denker <marcus.denker@inria.fr> wrote:
Well, it should be something like:
JENKINS = ci.inria.fr
Then the guard for the unit test could be
(OSPlatform current environment at: #JENKINS ifAbsent: [ '' ]) = 'ci.inria.fr' ifTrue: [ ^ self ]
to skip the test only on the INRIA CI servers.
Maybe CI instead of JENKINS is a more general name.
Ok, I added
CI = ci.inria.fr
to the windows slaves
OK, let's do this then:
== Name: Zinc-Zodiac-SvenVanCaekenberghe.28 Author: SvenVanCaekenberghe Time: 8 January 2014, 1:57:17.629973 pm UUID: 5c5d4ae3-5db1-4367-adfe-6341cda0fc41 Ancestors: Zinc-Zodiac-SvenVanCaekenberghe.27
Add a guard to ZnHTTPSTests>>#testGetPharoVersion to skip the whole test when #runningOnWindowsInriaCI ===
This is now in the upstream repositories, I will make a slice for https://pharo.fogbugz.com/f/cases/12377/ZnHTTPSTests-testGetPharoVersion-fai...
Sven
On 09 Jan 2014, at 17:29, btc@openinworld.com wrote:
Marcus Denker wrote:
12377 ZnHTTPSTests.>>testGetPharoVersion fails on Windows slave https://pharo.fogbugz.com/f/cases/12377
And this is just a build server artefact⦠(windows slave firewall problem).
I wonder what to do⦠maybe we could just skip it on windows when running on the build slave ;-)
Marcus
Was the DNS lookup error cannot resolve âci.inria.fr' the only problem? or would access to the server also be blocked? If only the former, did you consider preloading the DNS resolver cache from hosts file per [1], which provides a number of options: * refer to ci.inria.fr server via its a private subnet IP address, rather than the public facing IP address * fake up ci.inria.fr as a second IP address on the slave to which web server can be bound and configured to deliver the require file Of course the additional effort for these versus the gain needs to be balanced.
btw, useful commands for testing these are [2]: * ipconfig /displaydns * ipconfig /flushdns
[1] http://technet.microsoft.com/en-us/library/cc780585(v=ws.10).aspx [2] http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-...
No, the thing is: Does it make sense to invest a lot of time into this or are there not more important things? Marcus
On 09 Jan 2014, at 17:29, btc@openinworld.com wrote:
Marcus Denker wrote:
12377 ZnHTTPSTests.>>testGetPharoVersion fails on Windows slave https://pharo.fogbugz.com/f/cases/12377
And this is just a build server artefact⦠(windows slave firewall problem).
I wonder what to do⦠maybe we could just skip it on windows when running on the build slave ;-)
Marcus
Was the DNS lookup error cannot resolve âci.inria.fr' the only problem? or would access to the server also be blocked? If only the former, did you consider preloading the DNS resolver cache from hosts file per [1], which provides a number of options: * refer to ci.inria.fr server via its a private subnet IP address, rather than the public facing IP address * fake up ci.inria.fr as a second IP address on the slave to which web server can be bound and configured to deliver the require file Of course the additional effort for these versus the gain needs to be balanced.
btw, useful commands for testing these are [2]: * ipconfig /displaydns * ipconfig /flushdns
[1] http://technet.microsoft.com/en-us/library/cc780585(v=ws.10).aspx [2] http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-...
No, the thing is: Does it make sense to invest a lot of time into this or are there not more important things?
There is a point where I get endlessly tired⦠so many many many things, sometimes a simple workaround is just the easiest. Marcus
That is a great catch, thanks for the investigation, it requires somebody combining multi platform skills to fix this, there are not many of them ;-) So I guess we can try to re-enable the test... On 11 Jan 2014, at 17:48, btc@openinworld.com wrote:
Marcus Denker wrote:
On 09 Jan 2014, at 17:29, btc@openinworld.com wrote:
Marcus Denker wrote:
12377 ZnHTTPSTests.>>testGetPharoVersion fails on Windows slave
https://pharo.fogbugz.com/f/cases/12377
And this is just a build server artefact⦠(windows slave firewall problem).
I wonder what to do⦠maybe we could just skip it on windows when running on the build slave ;-)
Marcus
Was the DNS lookup error cannot resolve âci.inria.fr' the only problem? or would access to the server also be blocked? If only the former, did you consider preloading the DNS resolver cache from hosts file per [1], which provides a number of options: * refer to ci.inria.fr server via its a private subnet IP address, rather than the public facing IP address * fake up ci.inria.fr as a second IP address on the slave to which web server can be bound and configured to deliver the require file Of course the additional effort for these versus the gain needs to be balanced.
btw, useful commands for testing these are [2]: * ipconfig /displaydns * ipconfig /flushdns
[1] http://technet.microsoft.com/en-us/library/cc780585(v=ws.10).aspx [2] http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-...
No, the thing is: Does it make sense to invest a lot of time into this or are there not more important things?
There is a point where I get endlessly tired⦠so many many many things, sometimes a simple workaround is just the easiest.
Marcus Very true. Hence my disclaimer "the additional effort for these versus the gain needs to be balanced".
Actually it turns out my suggestions were over the top, since it seems the root cause is not the firewall but a difference in DNS resolver configuration between Windows and Linux. I had a poke around the pharo-contribution slaves since they are presumably similar to the pharo slaves. Slave pharo-contribution-linux64 was using nameserver 172.21.8.87 with a working 'ping ci.inria.fr', while slave pharo-contribution-win7 was using nameserver 172.21.32.8 (obtained from DHCP) with a non-working 'ping ci.inria.fr'. Forcing win7 DNS manually to use 172.21.8.87 allowed 'ping ci.inria.fr' to work and further the URL [1] worked fine from the Chrome browser returning [2].
Now it seems that bumping the network config has fixed this, since after undoing the manual win7 DNS setting, the DNS server (obtained from DHCP) is now 172.21.8.87. Someone with access to the Pharo Windows slaves might like to try the same.
cheers -ben
[1] https://ci.inria.fr/pharo/job/Pharo-2.0/lastSuccessfulBuild/api/xml?xpath=/*... [2] <description>2.0 #20628</description>
_Appendix - Detailed Transcript_
On slave pharo-contribution-linux64... # ping ci.inria.fr PING ci.inria.fr (193.51.193.223) 56(84) bytes of data. 64 bytes from ci.inria.fr (193.51.193.223): icmp_req=1 ttl=62 time=0.569 ms
#cat /etc/resolv.conf nameserver 172.21.8.87 nameserver 193.51.196.130 nameserver 193.51.196.131 search cs1cloud.internal
On slave pharo-contribution-win7... C:\Users\ci> ping ci.inria.fr Ping request could not find host ci.inria.fr. Please check the name and try again.
C:\Users\ci> ipconfig /all Ethernet adapter Local Area Connection: Description . . . . . . . . . . . : Intel(R) PRO/1000 MT Network Connection DHCP Server . . . . . . . . . . . : 172.21.8.87 DNS Servers . . . . . . . . . . . : 172.21.38.8 193.51.196.130 193.51.196.131
Through the GUI manually forced pharo-contribution-win7 to use nameserver 172.21.8.87, then... C:\Users\ci> ping ci.inria.fr Pinging ci.inria.fr [193.51.193.223] with 32 bytes of data: Reply from 193.51.193.223: bytes=32 time<1ms TTL=62
And after undoing that manual force... C:\Users\ci> ipconfig /all Ethernet adapter Local Area Connection: Description . . . . . . . . . . . : Intel(R) PRO/1000 MT Network Connection DHCP Server . . . . . . . . . . . : 172.21.8.87 DNS Servers . . . . . . . . . . . : 172.21.8.87 193.51.196.130 193.51.196.131
C:\Users\ci> ping ci.inria.fr Pinging ci.inria.fr [193.51.193.223] with 32 bytes of data: Reply from 193.51.193.223: bytes=32 time<1ms TTL=62
maybe we should add an issue tracker entry to not lose this? And no, sadly I have no time to do anything⦠On 11 Jan 2014, at 17:48, btc@openinworld.com wrote:
Marcus Denker wrote:
On 09 Jan 2014, at 17:29, btc@openinworld.com wrote:
Marcus Denker wrote:
12377 ZnHTTPSTests.>>testGetPharoVersion fails on Windows slave https://pharo.fogbugz.com/f/cases/12377
And this is just a build server artefact⦠(windows slave firewall problem).
I wonder what to do⦠maybe we could just skip it on windows when running on the build slave ;-)
Marcus
Was the DNS lookup error cannot resolve âci.inria.fr' the only problem? or would access to the server also be blocked? If only the former, did you consider preloading the DNS resolver cache from hosts file per [1], which provides a number of options: * refer to ci.inria.fr server via its a private subnet IP address, rather than the public facing IP address * fake up ci.inria.fr as a second IP address on the slave to which web server can be bound and configured to deliver the require file Of course the additional effort for these versus the gain needs to be balanced.
btw, useful commands for testing these are [2]: * ipconfig /displaydns * ipconfig /flushdns
[1] http://technet.microsoft.com/en-us/library/cc780585(v=ws.10).aspx [2] http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-...
No, the thing is: Does it make sense to invest a lot of time into this or are there not more important things?
There is a point where I get endlessly tired⦠so many many many things, sometimes a simple workaround is just the easiest.
Marcus
Very true. Hence my disclaimer "the additional effort for these versus the gain needs to be balanced".
Actually it turns out my suggestions were over the top, since it seems the root cause is not the firewall but a difference in DNS resolver configuration between Windows and Linux. I had a poke around the pharo-contribution slaves since they are presumably similar to the pharo slaves. Slave pharo-contribution-linux64 was using nameserver 172.21.8.87 with a working 'ping ci.inria.fr', while slave pharo-contribution-win7 was using nameserver 172.21.32.8 (obtained from DHCP) with a non-working 'ping ci.inria.fr'. Forcing win7 DNS manually to use 172.21.8.87 allowed 'ping ci.inria.fr' to work and further the URL [1] worked fine from the Chrome browser returning [2].
Now it seems that bumping the network config has fixed this, since after undoing the manual win7 DNS setting, the DNS server (obtained from DHCP) is now 172.21.8.87. Someone with access to the Pharo Windows slaves might like to try the same.
cheers -ben
[1] https://ci.inria.fr/pharo/job/Pharo-2.0/lastSuccessfulBuild/api/xml?xpath=/*... [2] <description>2.0 #20628</description>
_Appendix - Detailed Transcript_
On slave pharo-contribution-linux64... # ping ci.inria.fr PING ci.inria.fr (193.51.193.223) 56(84) bytes of data. 64 bytes from ci.inria.fr (193.51.193.223): icmp_req=1 ttl=62 time=0.569 ms
#cat /etc/resolv.conf nameserver 172.21.8.87 nameserver 193.51.196.130 nameserver 193.51.196.131 search cs1cloud.internal
On slave pharo-contribution-win7... C:\Users\ci> ping ci.inria.fr Ping request could not find host ci.inria.fr. Please check the name and try again.
C:\Users\ci> ipconfig /all Ethernet adapter Local Area Connection: Description . . . . . . . . . . . : Intel(R) PRO/1000 MT Network Connection DHCP Server . . . . . . . . . . . : 172.21.8.87 DNS Servers . . . . . . . . . . . : 172.21.38.8 193.51.196.130 193.51.196.131
Through the GUI manually forced pharo-contribution-win7 to use nameserver 172.21.8.87, then... C:\Users\ci> ping ci.inria.fr Pinging ci.inria.fr [193.51.193.223] with 32 bytes of data: Reply from 193.51.193.223: bytes=32 time<1ms TTL=62
And after undoing that manual force... C:\Users\ci> ipconfig /all Ethernet adapter Local Area Connection: Description . . . . . . . . . . . : Intel(R) PRO/1000 MT Network Connection DHCP Server . . . . . . . . . . . : 172.21.8.87 DNS Servers . . . . . . . . . . . : 172.21.8.87 193.51.196.130 193.51.196.131
C:\Users\ci> ping ci.inria.fr Pinging ci.inria.fr [193.51.193.223] with 32 bytes of data: Reply from 193.51.193.223: bytes=32 time<1ms TTL=62
participants (4)
-
btc＠openinworld.com -
Marcus Denker -
Norbert Hartl -
Sven Van Caekenberghe