如何解决从 JitPack 获取 jar 时,gradle 偶尔会超时
我的项目使用 gradle 构建,并且有一些依赖于 JitPack。有时,由于从 JitPack 获取 jar 时超时,构建失败:
> Task :preDebugBuild FAILED
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':preDebugBuild'.
> Could not resolve all files for configuration ':debugCompileClasspath'.
> Could not resolve org.traffxml:traff-eismoinfo-intensity:master-SNAPSHOT.
Required by:
project :
> Could not resolve org.traffxml:traff-eismoinfo-intensity:master-SNAPSHOT.
> Unable to load Maven meta-data from https://jitpack.io/org/traffxml/traff-eismoinfo-intensity/master-SNAPSHOT/maven-metadata.xml.
> Could not HEAD 'https://jitpack.io/org/traffxml/traff-eismoinfo-intensity/master-SNAPSHOT/maven-metadata.xml'.
> Read timed out
这似乎是 JitPack 的普遍问题。当请求一个不在缓存中的 jar 时,这显然需要更长的时间,因为 JitPack 必须首先构建 jar。但是,在这种情况下,master-SNAPSHOT
指的是一周前已经构建的版本,因此响应时间似乎是 JitPack 的普遍问题。我最多可以想象这与快照版本有关,因为 JitPack 每次都需要检查新版本——这可能意味着稳定版本不受影响。
对于本地构建,超时是一个小烦恼,因为我必须重新运行构建一两次,但在 CI 管道中,它会导致偶发性故障和大量手动干预或增加某些“超时后重试”逻辑的复杂性。
什么给?我可以在某处增加 gradle 的超时时间吗? JitPack 在非快照版本上的行为是否有所不同(因此此问题可能仅与开发版本相关,与依赖稳定版本而非快照的已发布版本相关)?
解决方法
您可以通过将这些添加到您的 gradle.properties
systemProp.org.gradle.internal.http.connectionTimeout=180000
systemProp.org.gradle.internal.http.socketTimeout=180000
您也可以从 ci 触发 Jitpack 构建,以增加在需要时缓存依赖项的可能性。
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。