我对GitLab很陌生。我已经通过.gitlab-ci.yml建立了管道和阶段，它们似乎可以工作，但是我发现我的某些假设是错误的。
我有一个大型的，多项目的Gradle设置，产生了许多工件。我们正在设置GitLab，我真的很想利用GitLab UI来显示构建进度。这个想法是要向开发人员和审阅者很好地指示构建在失败之前已经走了多远，例如：
我已经将每个设置为各自阶段的单独工作，（不正确地）假设Gradle将能够执行其增量构建魔术，并且这几乎与一步运行一样快。
然后我注意到每个阶段都会导致Docker容器重新初始化。这也意味着Gradle守护程序必须重新启动并且不了解过去。它必须获取所有依赖项。我想我可以缓存它们，但似乎它们会为每个作业单独缓存。最后，这些工作最终会重复之前已经完成的工作，因为它们的输出对他们不可用。我认为序列化作业将在同一容器实例中执行的想法被证明是错误的。通常，每个后续工作都必须重复之前已经完成的工作，从而显着增加了构建时间。
我想我知道我可以声明每个作业的工件，并以这种方式使它们可用于相关作业，但这并不能消除所有开销并增加了一些额外的开销-将工件复制到“某处”并然后回来，同时也达到了我可以传递的极限。实际上，我的单元测试工作现在失败了，由于日志大小的限制，我看不到为什么，但是似乎只与工件（报告）有关，因为当我在GitLab之外运行它们时，单元测试很好地通过了
我也认为我理解工作背后的想法是能够在单独的跑步者上并行运行它们。这是一个非常好的功能，我可能可以在以后的阶段中使用它们，但不适用于（1）-（5），因为它们严重依赖至少某些先前工作的大量输出。
出于性能方面的考虑，我可以将（1）-（5）合并到一个作业（和一个阶段）中，但是UI（我知道）中没有关于构建距离的指示。 ..并且即使取消了日志限制，日志也将更加冗长和费力。
您对我想念的东西有什么建议吗/应该在这里做什么？
答案 0 :(得分：1)
经过进一步研究，我发现这是不可能的（到目前为止）。显然，作业是（可能）并发执行的单元，并且只能通过复制工件进行通信。
我感兴趣的是步骤要比UI中指示的工作要少，并且可以在完成（步骤）但完成整个工作之前发布其工件。这将消除我现在面临的1-2分钟的作业启动开销。