Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Nebula test fails to get Gradle distribution #37

Open
davidmichaelkarr opened this issue Mar 25, 2015 · 9 comments
Open

Nebula test fails to get Gradle distribution #37

davidmichaelkarr opened this issue Mar 25, 2015 · 9 comments

Comments

@davidmichaelkarr
Copy link

I filed this SO posting: http://stackoverflow.com/questions/29262982/gradle-nebula-test-fails-to-download-gradle-distribution .

To reiterate, I had a working Gradle build, which had, and which continues to, download artifacts from the public internet (so Gradle has the correct proxy settings). I started to add nebula test so I could write integration tests. I first had to resolve a Spock version conflict (I was using 1.0, you're using 0.7). Once that was fixed, it seemed to try to go further, but then it fails with this:

Could not install Gradle distribution from 'https://services.gradle.org/distributions/gradle-2.3-bin.zip'.

The SO posting has the full stacktrace. What's curious is that although I'm able to set breakpoints in my plugin code in Eclipse and step through it, my attempts to set breakpoints in the nebula test code were seemingly ignored.

Note that I was even able to "wget" the same zip file from the same shell I ran the build from, and I noticed that wget pointed out that the initial request got a 301, and it redirected to the permanent location. Is this mechanism in nebula test not properly handling 301s?

@davidmichaelkarr
Copy link
Author

The key appears to be the proxy. How do I communicate proxy settings to nebula test?

@bmuschko
Copy link
Contributor

You might be running into GRADLE-1543. Do you experience the same issue when running gradle --daemon --stacktrace?

@davidmichaelkarr
Copy link
Author

Well, my problem now is that I don't see this anymore, most likely because I ran it once outside of the proxy, so now the bits are cached somewhere. What's the minimum I can do to reset this so it will try to do this again?

@bmuschko
Copy link
Contributor

bmuschko commented May 5, 2015

Probably by deleting ~/.gradle/wrapper.

@davidmichaelkarr
Copy link
Author

I'm hesitant to remove that while I'm at work behind the proxy, but I was able to repeat this by installing Gradle 2.4. I also installed the wrapper into my build script. I can build the entire application fine, but when I run the integration tests with 2.4, it fails trying to install the 2.4 distribution. I can then back off to 2.3 (which is still cached somewhere) and the integration tests pass.

@bmuschko
Copy link
Contributor

You might want to ask this question on the Gradle forum. This posting might help.

@davidmichaelkarr
Copy link
Author

This happened to me again. I had even forgot about this issue, and when I ran my tests in the office, they were failing trying to download the 2.4 distribution. I'm not sure why it was trying to do it again. I posted on the forum (again, forgetting about this issue) and they found no clues for why it was happening. When I got home, I ran the tests not on my VPN, and it downloaded the distro, and when I got back onto the VPN, they also worked.

And note that when I was getting this error, my ~/.gradle/wrapper/dists folder had a 2.4 distribution. When nebula-test finally downloaded a 2.4 distribution, nothing new appeared in that folder. When it downloaded the distro, I did see a path go by, but the saved lines in my console were too small, so I lost that info when I scrolled back later.

@davidmichaelkarr
Copy link
Author

Just to be consistent, I tried running my tests with Gradle 2.5 today, while in the office. Same error failing to get the 2.5 distribution. None of my proxy settings have changed, and I have no trouble reaching the internet.

When I get home, I'll run this again off VPN with "--debug" in a way that I can save the console output. Perhaps the info about where it's storing this distribution will be informative.

@davidmichaelkarr
Copy link
Author

If it matters, this is what I saw when I ran the tests with "--debug":

21:55:18.891 [DEBUG] [TestEventLogger] Running test from C:\Users\dk068x\workspace5\GradleYangPlugin\build\test\com.att.opnfv.yang.gradle.YangPluginIntegSpec\yangFilesRootDir-exists_1
21:55:19.143 [DEBUG] [TestEventLogger] Downloading https://services.gradle.org/distributions/gradle-2.5-bin.zip
21:55:26.630 [DEBUG] [TestEventLogger] ....
21:55:26.634 [DEBUG] [TestEventLogger] Unzipping C:\Users\dk068x.gradle\wrapper\dists\gradle-2.5-bin\7mk8vyobxfh3eazpg3pi2y9mv\gradle-2.5-bin.zip to C:\Users\dk068x.gradle\wrapper\dists\gradle-2.5-bin\7mk8vyobxfh3eazpg3pi2y9mv

21:55:27.611 [DEBUG] [TestEventLogger] Tooling API is using target Gradle version: 2.5.

After I got back on VPN and ran the tests again, they of course ran successfully.

I then deleted the "gradle-2.5-bin" folder that was created and ran the tests again, and they failed with the same error. I added "--daemon --stacktrace" as you describe above, and that produced the following info:

    org.gradle.tooling.GradleConnectionException: Could not install Gradle distribution from 'https://services.gradle.org/distributions/gradle-2.5-bin.zip'.
        at org.gradle.tooling.internal.consumer.DistributionFactory$ZippedDistribution$1.call(DistributionFactory.java:128)
        at org.gradle.tooling.internal.consumer.DistributionFactory$ZippedDistribution$1.call(DistributionFactory.java:116)
        at java.util.concurrent.FutureTask.run(FutureTask.java:262)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
        at java.lang.Thread.run(Thread.java:744)
        at org.gradle.tooling.internal.consumer.BlockingResultHandler.getResult(BlockingResultHandler.java:46)
        at org.gradle.tooling.internal.consumer.DefaultBuildLauncher.run(DefaultBuildLauncher.java:71)
        at nebula.test.functional.internal.toolingapi.BuildLauncherBackedGradleHandle.run(BuildLauncherBackedGradleHandle.groovy:81)
        at nebula.test.IntegrationSpec.runTasks(IntegrationSpec.groovy:264)
        at nebula.test.IntegrationSpec.runTasksSuccessfully(IntegrationSpec.groovy:249)
        ... 1 more

        Caused by:
        java.net.ConnectException: Connection timed out: connect

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants