为何gitlab-ci环境下运行Bitbake构建时解析receipts环节会卡住？

核心故障原因 #

• 伪终端(PTY)分配缺失
  GitLab CI Docker执行器默认不会给运行容器分配伪终端，且会关闭标准输入流。Bitbake 1.44版本调整了原有-i参数的生效逻辑，该参数仅对传统ncurses UI生效，默认的批处理UI依然会依赖stdin的交互检测逻辑，当检测到stdin为阻塞管道而非tty设备时，会无任何日志输出陷入等待。
  对应修复方案：在gitlab-ci.yml的对应job配置中增加tty: true参数，强制给容器分配伪终端；也可以在启动bitbake前添加环境变量export BBUI_NONINTERACTIVE=1强制关闭所有交互检测逻辑。
• ulimit资源限制过低
  GitLab CI Docker执行器默认的文件句柄限制通常为1024，远低于Bitbake解析数千个Recipe文件的需求。当解析阶段触发文件句柄耗尽时，进程会陷入内核资源等待，无任何应用层日志输出。
  对应修复方案：在构建脚本开头添加命令ulimit -n 65535，或者在GitLab Runner的config.toml的[[runners.docker]]配置段添加ulimit = ["nofile=65535:65535"]全局生效。
• 网络请求阻塞
  Bitbake解析阶段部分Recipe会默认触发上游元数据更新、源码地址有效性检测等网络请求。本地运行时通常配置了源缓存、代理策略，而CI容器网络默认隔离，若无对应内网源访问权限或代理配置，会陷入网络请求重试循环无输出。
  对应修复方案：在构建用的local.conf中添加配置BB_NO_NETWORK = "1"，强制关闭解析阶段的所有非必要网络请求；也可在CI环境中配置和本地一致的代理、内部Yocto源地址。
• 共享挂载目录IO阻塞
  GitLab CI默认会将构建目录CI_PROJECT_DIR作为宿主机共享目录挂载到容器中，若该目录存储在网络存储（NFS、NAS）、OverlayFS多层挂载路径下，Bitbake递归扫描Recipe目录时会触发IO阻塞，无进度输出。
  对应修复方案：将Yocto元数据目录、build目录放在容器内部的非共享路径下，仅将最终构建产物拷贝到CI_PROJECT_DIR用于归档。

快速排查方法 #

• 给bitbake启动命令增加-v -D参数，开启调试日志输出，确认卡住前最后执行的操作
• 在CI脚本中用strace -p $(pidof bitbake) -tt跟踪进程系统调用，可直接确认是卡在输入读取、文件打开还是网络连接环节

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