9

Naive use of the built-in settings sometimes results in hanging connections. It is likely some network issue outside of my control.

I would like to know how I can set a timeout and a retry for both downloading artifacts and publishing artifacts.

I have found a connection timeout and read timeout setting for HTTP wagon, but I have not found a retry option.

For publishing, I found a retry option, but no timeout setting.

Edit what I want is the equivalent of curl's --max-time, --retry and --retry-delay options for maven and gradle downloads and publishes.

030
  • 10,842
  • 12
  • 78
  • 123
Christian Goetze
  • 2,254
  • 3
  • 34
  • 51

2 Answers2

6

I tried to dig into this topic as well, but did not find much. Except one thing. Since Gradle 4.3 (thanks to PR) you can put to gradle.properties something like:

systemProp.org.gradle.internal.http.connectionTimeout=120000
systemProp.org.gradle.internal.http.socketTimeout=120000

Maybe once https://github.com/gradle/gradle/issues/4629 would be resolved, life will be much easier.

Jimilian
  • 3,859
  • 30
  • 33
-2

Gradle has built-in Maven compatability and it will create the .m2 or .gradle archive directories for you. To retry, all you need to do is just re-run your build over and over until all artifacts are complete.

djangofan
  • 28,471
  • 61
  • 196
  • 289
  • 1
    To flesh this out a little: you are suggesting that I place a build timeout at some reasonable time, probably determined by past build performance, then abort the build, then examine the build log to see if the failure was due to a network download or upload issue, then retry if yes - hmmmmm...... – Christian Goetze Apr 24 '14 at 00:52
  • An alternative is to require that the build always be done in three steps: first resolve all artifact dependencies, and implement a timeout/retry via shell or some kind of launcher; then build, and finally, if the build succeeds, perform the publish again via some kind of retrying launcher. That might actually be somewhat do-able, even if it begs the question.... – Christian Goetze Apr 24 '14 at 01:00
  • No, what I mean is that Gradle (and maven) already know how to retry for failed downloads of artifacts and so you dont need to code anything for that. Simply run the build again and the next try will hopefully succeed in getting at least 1 more artifact. Then, keep repeating. – djangofan Apr 24 '14 at 16:20
  • And I suppose I need to parse the log to distinguish between a genuine build failure and a download failure? That's why I was suggesting to run the build in multiple steps... – Christian Goetze Apr 25 '14 at 16:07
  • Just write a unit test to verify the build success. If the unit test fails, then run the build again. If the unit test passes, then you probably have all the artifacts downloaded. Be careful not to overthink things and re-invent wheels. – djangofan Apr 25 '14 at 20:22
  • This really doesn't help. It seems like a simple request to retry a network resource when it fails. I don't want to retry the whole build. – mjaggard Nov 15 '17 at 16:04