My favorites | Sign in
Project Home Downloads Wiki Issues Source
New issue   Search
for
  Advanced search   Search tips   Subscriptions
Issue 489: mvn package fails in reason of failed testcase: testResolve(com.google.gerrit.server.util.SocketUtilTest)
  Back to list
Status:  Released
Owner:  ----
Closed:  Oct 2012


Sign in to add a comment
 
Reported by cbaldacin@gmail.com, Mar 5, 2010
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
Can you include the actual log file from that test?
It should be under gerrit-server/target/surefire-reports
and be named com.google.gerrit.server.util.SocketUtilTest.txt
Status: AwaitingInformation
Mar 5, 2010
#2 sop@google.com
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
#3 cbaldacin@gmail.com
Attaching the required log file...
com.google.gerrit.server.util.SocketUtilTest.txt
594 bytes   View   Download
Mar 8, 2010
#4 sop@google.com
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
Project Member #5 Shane...@gmail.com
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
#6 cbaldacin@gmail.com
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
#7 sop@google.com
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
#8 sop@google.com
Fixed in 2.1.2 when I dropped the test.
Status: Fixed
Labels: -Milestone-2.1.2 FixedIn-2.1.2
Oct 21, 2012
#9 sop@google.com
(No comment was entered for this change.)
Status: Released
Sign in to add a comment

Powered by Google Project Hosting