gradle - 如何设置 GitLab CI 以高效运行多个构建步骤，同时指示它在哪一步？

Question

我是 GitLab 的新手。我已经通过 .gitlab-ci.yml 设置了管道和阶段，它们似乎有效，但我刚刚发现我的一些假设是错误的。

我有一个大型的多项目 Gradle 设置，生成了许多工件。我们正在设置 GitLab，我真的很想利用 GitLab UI 来显示构建进度。这个想法是为了向开发人员和审阅者很好地指示构建在失败之前进行了多远，例如:

1. 得到它的依赖
2. 已编译主要代码，耶!
3. 编译测试代码，yippie!
4. 通过了单元测试，我们很高兴!
5. 通过了集成测试，太棒了!
6. 通过了各种静态代码分析测试。我们几乎可以出发了!
7. 生成的文档 - 我们可以发货吗？

我已将其中的每一项都设置为各自阶段的独立作业，(错误地)假设 Gradle 将能够执行其增量构建魔法，并且这几乎与将其作为单个步骤运行一样快。

然后我注意到每个阶段都会导致 Docker 容器重新初始化。这也意味着 Gradle 守护进程必须重新启动并且不知道过去。它必须获得所有依赖项。我想我可以缓存这些，但似乎它们会为每个作业单独缓存。最后，这些作业最终会重复它们之前已经做过的作业，因为它们的输出对它们不可用。我认为序列化作业将在同一个容器实例中执行的想法被证明是错误的。每个后续作业通常都必须重复之前的作业已经完成的工作，这会显着增加构建时间。

我想我明白我可以声明每个作业的工件并以这种方式使它们可用于相关作业，但这并没有消除所有开销并增加了一些它自己的开销 - 将工件复制到“某处”并且然后回来，同时也达到了我可以传递多少的极限。事实上，我的单​​元测试工作现在失败了，由于日志大小限制，我不明白为什么，但它似乎只与工件(报告)有关，因为当我在 GitLab 之外运行它们时，单元测试很好地通过了.

我也认为我理解作业背后的想法是能够在不同的运行器上并行运行它们。这是一个非常好的功能，我可能可以在后面的阶段使用它们，但不能用于 (1)-(5)，因为它们严重依赖于至少一些之前工作的大量输出。

出于性能原因，我可以将 (1)-(5) 合并到一个作业(和一个阶段)中，但是在 UI 中(据我所知)没有指示构建完成了多远。 .. 即使取消了日志限制，日志也会变得更长更难弄清楚。

对于我在这里遗漏/应该做什么，你们有什么建议吗？

Answer 1

经过进一步研究，我发现这是不可能的(还)。显然，作业是(可能)并发执行的单元，并且只能通过复制工件进行通信。

我感兴趣的是比将在 UI 中指示的作业更少的步骤，并且可以在它们(步骤)完成但在整个作业完成之前发布它们的工件。这将消除我现在面临的 1-2 分钟的工作启动开销。