链自动构build在同一个Docker Hub存储库中
由于在Docker Hub上构build时间限制 ，我决定将耗时的自动构build的Dockerfile分解成3个文件。 这些“子版本”中的每一个都在Docker Hub的时间限制内完成。
我现在在同一个仓库中有以下设置：
| branch | dockerfile | tag | | ------ | ------------------ | ------ | | master | /step-1.Dockerfile | step-1 | | master | /step-2.Dockerfile | step-2 | | master | /step-3.Dockerfile | step-3 |
这些图像按以下顺序相互build立：
-
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 Hub提供的“构build触发器”URL触发构buildstep-1 。 （向其中添加{"docker_tag": "step-1"}'有效载荷）但是，Docker Hub并未提供自动触发step-2 step-3后缀的方法。
问：我如何自动按照各自的顺序触发以下构build步骤？ （即在step-1完成后触发step-2 ，然后在step-2完成后触发step-3 ）
注意：我不想为每个step-i设置单独的存储库，然后使用Docker Hub的“存储库链接”链接它们。 我只想链接在相同的回购标签 。
注意：到目前为止，我的解决scheme是将Docker Hub Webhook连接到我所做的Web应用程序。 当step-n完成时，（即使用包含step-n标签名称的JSON调用我的web应用程序的URL），web应用程序使用“构build触发器”触发step-n+1 。 它按预期工作，但是，我想知道是否有一个“更好”的做事方式。
编辑： 按照肯·科克伦的要求这里是最初的Dockerfile以及它使用的“构build脚本” 。 我只是试图将docker装上去。 （一个C ++解释器）需要编译llvm，clang和cling。 正如你所期望的那样，根据机器的不同，它需要几个小时才能完成，而Docker Hub最多只允许2小时的构build:)稍后添加的“子构build”镜像（仍在develop分支中）分别构build整个事物的一部分。 我不确定这里是否有进一步的优化。
另外，为了testing各种想法（并避免等待结果h小时），我已经build立了另一个类似结构的回购 。 （唯一的区别是它的Dockerfile没有做太多的工作）
更新1：在选项5上 ：正如所料，来自step-1.Dockerfile的curl被忽略：
Settings > Build Triggers > Last 10 Trigger Logs | 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 Hub有一个选项来使其无效并重新生成另一个）
更新2：这是我目前的尝试 ：它基本上是一个Heroku主机的应用程序，有一个APScheduler周期性的“触发器”，启动初始构build步骤，以及一个Flask webhook处理程序“传播”构build。 （也就是说它有构build标签的有序列表，每次被webhook调用时，它会触发下一个构build步骤），我将在业余时间继续这个工作。 （build议欢迎:)）
build设需要多长时间？ 你可以发布你的Dockerfile吗？
选项1：找出自动化构build需要花费的时间，以了解为什么不能及时完成。 如果你在这里发布，我们可以看看是否有什么可以做的优化。
选项2：你现在正在做什么，使用第三方应用程序触发按给定顺序的构build。
选项3：我不确定这是否适用于您，因为您使用的是相同的回购协议，但通常您会使用此function的回购链接，然后链接它们，当一个完成时，下一个触发第一个。 但既然你有一个回购，它将无法正常工作。
选项4：分解成多个回购，然后你可以使用回购链接。
选项5：完全破解，最后的手段（不知道它是否会工作）。 你在Dockerfile的最后一行添加一个CURL语句，用下一步的给定标签发布到repo的构build触发器链接。 如果下一步需要一个标记，则可能需要在下一步添加一个睡眠，以等待推送完成被推送到集线器。
老实说，最好的select是：select1：你所做的事应该能够在指定的时间内完成，你可能正在做一些我们可以优化的东西，以使整个事情更快。 如果你在规定的时间内到达，那么一切都是不需要的。
最近有相同的要求链式依赖的构build，并使用Docker Cloud自动构build以这种方式实现：
- 为每个需要构build的
Dockerfile创build一个具有构build规则的存储库。 - 禁用从属存储库中的所有构build规则的自动构build选项。
-
在包含
hooks\post_push的每个目录中添加一个名为hooks\post_push的shell脚本，该Dockerfile具有以下代码的依赖项：for url in $(echo $BUILD_TRIGGERS | sed "s/,/ /g"); do curl -X POST -H "Content-Type: application/json" --data "{ \"build\": true, \"source_name\": \"$SOURCE_BRANCH\" }" $url done -
对于每个具有依赖项的存储库，都将一个名为
BUILD_TRIGGERS的Build Environment Variable添加到自动构build中，并将Value设置为每个依赖自动构build的构build触发器URL的逗号分隔列表。
使用这个设置，一个push到根源仓库将会触发一个根镜像的构build，一旦它完成，并被post_push挂钩将被执行。 在钩子中，对每个依赖的存储库构build触发器进行POST，其中包含在请求主体中构build的分支或标记的名称。 这将导致触发相关存储库的相应构build规则。
通过调整Docker Hub仓库中的Build Settings可以做到这一点。
首先，为您的GitHub仓库的/step-1.Dockerfile创build一个自动构build，标记为step-1 。 这一个不需要任何特殊的设置。
接下来，为您的GitHub仓库的/step-2.Dockerfile创build另一个自动构build，标记为step-2 。 在“生成设置”中，取消选中“ 活动”时，生成将在推送时自动发生 。 还要添加一个存储库链接到me/step-1 。
step-3 （链接到me/step-2 ）也一样。
现在，当你推送到GitHub仓库时，它将触发第一步构build; 当完成时，步骤2将build立，然后，步骤3将build立。
请注意，您需要等待上一阶段才能成功构build一次，然后才能向其添加存储库链接。