问如何设置GitLab CI以有效地运行多个构建步骤，同时指出它在哪个步骤？

EN

我对GitLab很陌生。我已经通过..gitlab ci.yml建立了管道和阶段，它们似乎有效，但我发现我的一些假设是错误的。

我有一个大型的，多项目的分级设置，生产许多工件。我们正在设置GitLab，我非常想利用GitLab UI来显示构建的进度。这样做的目的是很好地向开发人员和评审人员表明，构建在失败之前已经走了多远，比如：

1. 得到它的依赖项
2. 编译主要代码，YAY！
3. 编译测试代码，伊皮！
4. 通过了单元测试，我们成功了！
5. 通过了集成测试，太棒了！
6. 通过了各种静态代码分析测试。我们差不多可以出发了！
7. 生成的文档-我们能寄出它吗？

我已经将每个任务设置为其各个阶段的单个作业，(错误地)假设Gradle能够执行其增量构建魔术，并且这将几乎与运行它的单个步骤一样快。

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

我想我明白，我可以声明每个作业的工件，并以这种方式将它们提供给依赖作业，但这并不能消除所有的开销，并增加一些自己的开销--将工件复制到“某个地方”，然后返回，同时也达到了我可以传递多少的极限。事实上，我的单元测试工作现在失败了，而且由于日志大小的限制，我无法理解为什么，但是当我在GitLab之外运行它们时，它似乎只与工件(报告)有关。

我还认为我明白，工作背后的想法是能够在不同的跑步者上并行运行。这是一个非常好的特性，我可能可以在以后的阶段使用它们，但不能用于(1)-(5)，因为它们严重依赖于至少一些以前的工作的大量输出。

出于性能原因，我可以将(1)-(5)合并成单个任务(和一个阶段)，但在UI中(据我所知)没有任何迹象表明构建有多远.即使木头的限制被取消了，要弄清楚这些圆木还会更长、更难弄清楚。

你们中有谁对我在这里缺少什么/应该做什么有什么建议吗？