-
Notifications
You must be signed in to change notification settings - Fork 18
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
Comments
The key appears to be the proxy. How do I communicate proxy settings to nebula test? |
You might be running into GRADLE-1543. Do you experience the same issue when running |
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? |
Probably by deleting |
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. |
You might want to ask this question on the Gradle forum. This posting might help. |
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. |
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. |
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: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:
|
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:
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?
The text was updated successfully, but these errors were encountered: