Bitbucket Pipelines自托管Runner使用DinD时克隆仓库报错问题

问题1：是否支持通过Bitbucket Pipelines直接在自托管主机本机运行CI任务，而非在主机内的Docker容器中执行？ #

• 该能力暂不支持。
  当前Bitbucket自托管Runner的执行逻辑固定为：在匹配标签的宿主机上拉起独立Docker容器作为CI任务的运行环境，所有构建、测试、部署步骤都在容器内执行，无法直接绕过容器层在宿主机原生环境运行任务。
  你当前使用的基础Runner标签配置如下，该配置默认就会触发容器化执行逻辑：

runs-on:
  - "self.hosted"
  - "ubuntu18.04"

问题2：配置DinD方案使用自定义构建环境时，克隆阶段报retry: command not found错误的根因是什么？ #

核心故障根因 #

• 你通过CLONE_IMAGE参数指定的自定义镜像不符合Bitbucket Pipelines克隆阶段的环境要求。
  Bitbucket官方默认提供的Pipelines执行/克隆镜像内置了整套CI流程依赖的基础shell工具、预置函数，你使用的干净自定义镜像没有这些预置内容，直接替换CLONE_IMAGE就会导致克隆脚本执行时找不到依赖组件，触发runner.bitbucket-pipelines.clone-container-failure报错。

关于找不到的retry命令说明 #

• 日志中报错的retry不是Ubuntu apt源中提供的第三方retry工具包，是Bitbucket官方镜像内置的shell函数，作用是按指定次数重试失败的Git克隆操作，你通过sudo apt install retry安装的程序和Pipelines依赖的内置实现完全不匹配，无法解决该故障。
• 日志Docker标签页下的/var/run/docker.sock用户组警告、2375端口无TLS绑定警告属于DinD模式的常规提示，不是本次克隆失败的诱因。

推荐解决方案 #

针对你提到的「默认容器缺少运行环境、每次启动临时初始化耗时过长」的问题，不需要强行替换CLONE_IMAGE走DinD嵌套方案，可选择以下更稳定的实现方式：

• 基于Bitbucket官方提供的默认Runner基础镜像做二次构建，把任务所需的运行时、依赖库、工具链提前打包进自定义镜像，镜像内会天然保留Pipelines所需的retry等内置组件，任务启动时不需要重复安装依赖，可大幅压缩构建耗时。
• Pipeline配置中不需要单独指定CLONE_IMAGE，克隆阶段会自动使用兼容的官方镜像完成代码拉取，后续构建、测试步骤直接指定你预构建好的自定义镜像作为执行环境即可，完全规避克隆阶段的依赖缺失问题。

内容的提问来源于stack exchange，提问作者CiaranWelsh