Question

我们的构建服务器输出如下所示

[13:24:09][Step 1/1] [info] Loading project definition from ...
[13:24:10][Step 1/1] [info] Set current project ...
[13:24:10][Step 1/1] [info] Updating {file:/Users/build/TeamCity/agents/agent1/work/6060f176dc49a319/}root...
[13:24:11][Step 1/1] [info] Resolving org.scala-lang#scala-library;2.10.4 ...
... blah blah
[13:24:16][Step 1/1] [info] Done updating.
[13:26:42][Step 1/1] [success] Total time: 146 s, completed 24-Jul-2014 13:26:42

因此，完成解决步骤需要几秒钟，但在Done updating和下一步之间需要几分钟的暂停。

知道那里发生了什么吗？

Answer 1

我不是100％确定它是在显示“完成更新”之前还是之后，但是围绕常春藤解决方案发生了两件事：缓存和编写解决方案报告。通过编译调用更新，因此缓存结果很重要。如果您有一个大的依赖关系图，缓存输入和输出可能需要几秒钟。常春藤解析报告写到target/resolution-cache/reports/目录，它可以准确地告诉您哪些模块和工件得到了解决。这是为每个配置写出的大型XML文件，因此也可能需要几秒钟。如果您有多个具有大依赖关系的子项目，那么所有这些都可以复合到很多秒。

我目前正在研究与sbt相关的几个功能。如果子项目具有相当统一的依赖关系，Consolidated resolution应该可以减轻多项目构建的痛苦。使用决议报告的结果，我将产生驱逐警告。

Answer 2

我们发现通过完全清理我们的目标目录，问题就消失了:(

我们正在使用

  cleanKeepFiles ++= Seq("resolution-cache", "streams").map(target.value / _)

这可能是罪魁祸首，谁知道呢。

如果再次发生，我会尝试了解最新情况。

为什么sbt在解决后暂停？

2 个答案: