По какой-то причине gradle не загружает зависимости из Maven Central. У нас также настроен частный репозиторий Nexus, и по какой-то причине gradle ищет там зависимости, а не Maven Central.
Я получаю массу ошибок, похожих на:
Failed to get resource: HEAD. [HTTP HTTP/1.1 400 Repository version policy: SNAPSHOT does not allow version: 1.5.0.RELEASE: http://*****/repository/******/io/pivotal/spring/cloud/spring-cloud-services-dependencies/1.5.0.RELEASE/spring-cloud-services-dependencies-1.5.0.RELEASE.pom]
Клянусь, я решил это раньше, когда впервые настроил его, но не могу воспроизвести. Чтобы я мог попасть в Maven Central, я должен настроить прокси-сервер и использовать Nexus в качестве исключения для прокси-сервера.
Все это работает локально, но проблема возникает при работе с Jenkins и плагином Sonarqube. Локально я пробовал различные настройки прокси (удалить systemProps или даже системные переменные env), но ошибки не совпадают (например, не удается найти хост).
Есть идеи, почему он не может загружаться с Maven Central?
Обновление: так что я смог немного сузить его. При использовании блока Jenkins и Sonarqube withSonarQubeEnv
что-то происходит с тем, как gradle разрешает зависимости. См. 3 примера:
// #1 This breaks when SNAPSHOT is declared first
repositories {
maven { // <------------------ SNAPSHOT
credentials {
username usr
password pass
}
url uri(snapshot)
}
maven { // <------------------ RELEASE
credentials {
username usr
password pass
}
url uri(release)
}
mavenCentral() // <---------- Maven Central
}
// #2 This works since mavenCentral() is first:
repositories {
mavenCentral() // <---------- Maven Central
maven { // <------------------ SNAPSHOT
credentials {
username usr
password pass
}
url uri(snapshot)
}
maven { // <------------------ RELEASE
credentials {
username usr
password pass
}
url uri(release)
}
}
// #3 This also works because no failing version policy:
repositories {
maven { // <------------------ RELEASE
credentials {
username usr
password pass
}
url uri(release)
}
mavenCentral() // <---------- Maven Central
}
Это отлично работает, если не использовать withSonarQubeEnv
в Jenkins. Почему порядок имеет значение при использовании withSonarQubeEnv
?
build
вместо задачиsonarqube
gradle и получил те же ошибки. Я думаю, что это как-то связано с настройкойwithSonarQubeEnv
. Я предположил, что сбрасываются настройки прокси, поэтому я добавил в негоwithEnv
и никаких изменений. Я также проверил журналы демона gradle, чтобы увидеть, что переменные среды прокси были установлены, и они были установлены. Кроме того, я добавил задачу gradle, чтобы увидеть, что настройки прокси-сервера gradle.properties все еще там, и они были. Не знаю, почему добавлениеwithSonarQubeEnv
вызывает это. Любые идеи? - person Brandon   schedule 06.02.2018