在同一个Docker集线器存储库中自动构建链

Question

由于要在Docker上构建时间限制，我决定将一个耗时的自动构建的Dockerfile分成三个文件。每个“子构建”都在码头中心的时限内完成。

我现在在同一个存储库中设置了以下内容：

| branch | dockerfile         | tag    |
| ------ | ------------------ | ------ |
| master | /step-1.Dockerfile | step-1 |
| master | /step-2.Dockerfile | step-2 |
| master | /step-3.Dockerfile | step-3 |

这些图像按以下顺序相互生成：

• step-1.Dockerfile：FROM ubuntu
• step-2.Dockerfile：FROM me/complex-image:step-1
• step-3.Dockerfile：FROM me/complex-image:step-2

一个单独的web应用程序使用Docker提供的“构建触发器”URL (添加了step-1有效负载)触发{"docker_tag": "step-1"}'的构建。然而，Docker并没有提供一种自动触发step-2，然后触发step-3的方法。

如何按照各自的顺序自动触发以下构建步骤？**(即，在step-2完成后触发step-1。然后，在step-3完成后触发step-2 )。

NB:我不想为每个设置单独的存储库，然后使用Docker的"Repository链接“链接它们。--我只想将标记链接到同一个存储库中。

注释：到目前为止，我的解决方案是将一个DockerHubWeb钩子附加到我制作的web应用程序中。当step-n完成时(即用包含step-n标记名的JSON文件调用web应用程序的URL )，web应用程序使用“构建触发器”触发step-n+1。不过，我想知道是否有一种“更好”的做事方式。

应肯·科克伦的要求，这是它使用的Dockerfile和“构建脚本”。我只是想篡改固守 (一个C++解释器)。它需要编译LLVM、嘎吱声和固守。正如您所预期的，取决于机器，它需要几个小时才能完成，而Docker最多允许“只”2小时构建:)我后来添加的“子构建”映像(仍然在develop分支中)构建了每件事情的一部分。我不确定这里是否有任何进一步的优化。

此外，为了测试各种想法(并避免等待h小时以获得结果)，我已经使用类似的结构设置了另一个储存库 (唯一的区别是它的Dockerfile没有做那么多工作)。

更新1: On 备选方案5：正如预期的那样，来自step-1.Dockerfile的curl被忽略了：

设置→生成触发器→最后10个触发器日志

| Date/Time                 | IP Address      | Status  | Status Description       | Request Body               | Build Request |
| ------------------------- | --------------- | ------- | ------------------------ | -------------------------- | ------------- |
| April 30th, 2016, 1:18 am | <my.ip.v4.addr> | ignored | Ignored, build throttle. | {u'docker_tag': u'step-2'} | null          |

这种方法的另一个问题是，它要求我在Dockerfile中放置构建触发器的(秘密)令牌，让每个人都能看到:) (希望Docker可以选择使其失效并重新生成另一个令牌)

更新2:这里是我目前的尝试：它基本上是一个具有启动初始构建步骤的APScheduler周期性“触发器”的赫鲁库-hosted应用程序，以及一个“传播”构建的烧瓶 Web钩子处理程序(即，它有有序的构建标记列表)。每次被web钩子调用时，它都会触发下一个构建步骤)。

Answer 1

最近，我也有了链接依赖构建的同样要求，并使用Docker自动构建以这种方式实现了它：

• 为每个需要构建的Dockerfile创建一个包含构建规则的存储库。
• 禁用依赖存储库中所有生成规则的Autobuild选项。
• 在每个目录中添加一个名为hooks\post_push的shell脚本，其中包含与以下代码相关的Dockerfile： 对于$中的url ( $BUILD_TRIGGERS //，//g)；做curl -X POST -H "Content-Type: application/json“--数据"{ \”build\：true，\"source_name\"：\"$SOURCE_BRANCH\“}”$url done“
• 对于每个具有受抚养人的存储库，向自动构建中添加一个名为BUILD_TRIGGERS的构建环境变量，并将Value设置为每个依赖的自动构建的构建触发器URL的逗号分隔列表。

使用此设置，对根源存储库的推送将触发根映像的构建，一旦它完成并被推送，将执行post_push钩子。在钩子中，对每个依赖的存储库生成触发器进行帖子，其中包含正在请求正文中构建的分支或标记的名称。这将导致触发依赖存储库的适当构建规则。

Answer 2

建造需要多长时间？你能把你的码头文件寄出去吗？

选项1:找出为什么您的自动化构建花费这么长时间，以了解为什么它没有及时完成。如果您在这里发布它，我们可以看到是否有什么您可以做的优化。

选项2:是您现在已经在做的，使用第三方应用程序以给定的顺序触发构建。

选项3:我不确定这是否适用于您，因为您使用的是相同的回购，但通常您会使用回购链接的这一功能，然后连锁，当一个完成，下一个触发第一个。但既然你有一次回购，那就没用了。

选项4:将其分解为多个repos，然后您可以使用回购链接。

备选方案5:完全黑客，最后手段(不确定它是否会起作用)。在Dockerfile的最后一行中添加一个CURL语句，将其发布到带有给定标记的repo的构建触发器链接中，以便下一步工作。如果下一步需要一个标记，则可能需要在下一步中添加一个睡眠，以等待推送完成对集线器的推送。

老实说，最好的选择1:无论你做什么都应该能够在规定的时间内完成，你可能正在做一些事情，我们可以优化，使整个事情更快。如果你让它在规定的时间内进入，那么其他的一切都是不必要的。

Answer 3

可以通过调整Docker存储库中的构建设置来做到这一点。

首先，使用标记/step-1.Dockerfile为GitHub存储库的step-1创建一个自动构建。这个不需要任何特殊设置。

接下来，使用标记/step-2.Dockerfile为GitHub存储库的step-2创建另一个自动构建。在“生成设置”中，取消选中“活动时的”，生成将自动发生在推送上。还向me/step-1添加一个存储库链接。

对step-3也这样做(将其链接到me/step-2)。

现在，当您推入GitHub存储库时，它将触发步骤1进行构建；当步骤2完成时，步骤2将生成，之后，步骤3将生成。

请注意，您需要等待上一阶段成功构建一次，然后才能向其添加存储库链接。