| Issue 489: | mvn package fails in reason of failed testcase: testResolve(com.google.gerrit.server.util.SocketUtilTest) | |
| Back to list |
Affected Version: 2.1.2-rc2-33-g7e30c72 What steps will reproduce the problem? 1.git clone 2.mvn package What is the expected output? What do you see instead? Results : Failed tests: testResolve(com.google.gerrit.server.util.SocketUtilTest) Tests run: 110, Failures: 1, Errors: 0, Skipped: 0 [INFO] ------------------------------------------------------------------------ [ERROR] BUILD FAILURE [INFO] ------------------------------------------------------------------------ [INFO] There are test failures. Please provide any additional information below. It happens only on Mac OS, I've tried in another ubuntu machine and it worked properly. I have removed the testcase also, it seems that all works ok unless the gerrit run/debug via eclipse which throws the following: Exception in thread "main" java.lang.NoClassDefFoundError: com/google/gerrit/pgm/daemon (wrong name: com/google/gerrit/pgm/Daemon) Does anybody knows what it might be?
Mar 5, 2010
#1
sop@google.com
Status:
AwaitingInformation
Mar 5, 2010
The problem with running the daemon on Mac OS X from Eclipse is unrelated to the test failure. I've moved it into its own bug as issue 490 .
Mar 8, 2010
Attaching the required log file...
Mar 8, 2010
Hmm. Your DNS system resolved the hostname "this-name-is-not-supposed-to-resolve-on-your-network" to an actual IP address. The test assumes that this won't resolve, and is testing for that error condition. Odd choice in hostname. I wonder if I changed the test name to be a random smattering of characters if it would be more likely to fail, e.g. change it to "HO3bcTgYMt1Aa9uANcobQjBpmw3RodHyVl6xPy9LqUNIHjj22QhF9448IidG"
Mar 8, 2010
My home network has a *.home.mydomain.com record in DNS, dhcp clients are *.dhcp.mydomain.com but servers are on *.home.mydomain.com so any of my home servers will happily resolve anything.home.mydomain.com Something similar could explain the hostname existing elsewhere.
Mar 8, 2010
well, I've checked with the IT guys here, and they use opendns (www.opendns.com) for this network so that any character sequence resolves to "http://guide.opendns.com/?url=blablablablabla" for instance. Therefore, a random smattering of characters would not fix in this case.
Mar 8, 2010
Well, to be fair, OpenDNS is flagrantly breaking the DNS protocol. Returning an IP address that might be running an HTTP server that can try to do a web search based on the Host header sent by the browser assumes all uses of DNS is an HTTP client. Clearly, that isn't true. I've dropped the test entirely from the test suite. Its proven to be more trouble than it is worth. See Ia9eb79ae97841003e0d1e82bf0deae4ca61b97ad
Status:
Started
Labels: Milestone-2.1.2
Mar 12, 2010
Fixed in 2.1.2 when I dropped the test.
Status:
Fixed
Labels: -Milestone-2.1.2 FixedIn-2.1.2
Oct 21, 2012
(No comment was entered for this change.)
Status:
Released
|
|
| ► Sign in to add a comment |