如果项目有多个可用的跑步者，gitlab ci如何决定使用哪个跑步者？
我有一个omnibus gitlab 8.6.6-ee安装，配置了2个跑步者 . 跑者是相同的（docker图像，配置等），除了它们在不同的计算机上运行 .
如果他们都是空闲的，那么他们中的任何一个都可以运行，哪个会运行？
为了增加Rubinum的答案，“第一个”跑步者将是首先检查符合所有标准的跑步者 . 例如，标签可以限制运行某些作业的运行者 .
跑步者每X秒查询gitlab服务器以检查是否有构建 . 如果有一个排队和多个满足标准，那么第一个问题就会赢
Update to answer comments:
运行者通过CI API http://docs.gitlab.com/ce/ci/api/builds.html进行通信以获取构建状态 . 这最终意味着它将成为一个或多或少随机选择的跑步者，基于它完成最后一个工作的时间和 x 等待检查的数量 .
x
To completely answer the question:
在挖掘代码并根据this和this找到 x = 3 秒之后，信用转到BM5k . 还发现：
x = 3
一旦选择了跑步者，一个码头机机器将使用哪台机器）显示机器选择或多或少（有效）随机
Gitlab CI为那些可用的跑步者分配工作 . 如果由于忙碌而无法获得跑步者，那么Gitlab CI会将该作业分配给其他可用的跑步者 . 在您的情况下，它将始终将作业分配给第一个跑步者（无论是谁） .
如果你想在特定的跑步者/ mashine上指定执行，那么看看我的帖子here.
在我看来，如果你使用的是docker，那么不知道哪个跑步者将运行你的构建是很好的，因为这是跑步者/码头 Worker archeticture的好处 .
2 回答
为了增加Rubinum的答案，“第一个”跑步者将是首先检查符合所有标准的跑步者 . 例如，标签可以限制运行某些作业的运行者 .
跑步者每X秒查询gitlab服务器以检查是否有构建 . 如果有一个排队和多个满足标准，那么第一个问题就会赢
Update to answer comments:
运行者通过CI API http://docs.gitlab.com/ce/ci/api/builds.html进行通信以获取构建状态 . 这最终意味着它将成为一个或多或少随机选择的跑步者，基于它完成最后一个工作的时间和
x等待检查的数量 .To completely answer the question:
在挖掘代码并根据this和this找到
x = 3秒之后，信用转到BM5k . 还发现：Gitlab CI为那些可用的跑步者分配工作 . 如果由于忙碌而无法获得跑步者，那么Gitlab CI会将该作业分配给其他可用的跑步者 . 在您的情况下，它将始终将作业分配给第一个跑步者（无论是谁） .
如果你想在特定的跑步者/ mashine上指定执行，那么看看我的帖子here.
在我看来，如果你使用的是docker，那么不知道哪个跑步者将运行你的构建是很好的，因为这是跑步者/码头 Worker archeticture的好处 .