Gitlab CI任务返回值为0仍失败，疑为Docker镜像问题

我有一个GitLab CI任务，尽管最后一条命令返回值为0，但任务仍失败。执行仅包含ps -a和echo $?的极简脚本时，日志如下：

$ ps -A
    PID TTY          TIME CMD
      1 ?        00:00:00 bash
      9 ?        00:00:00 bash
     19 ?        00:00:00 ps
$ echo $?
0
Cleaning up file based variables 00:01
ERROR: Job failed: exit code 1

已将问题定位到所使用的Docker镜像——在同一运行器上使用其他镜像时，该任务可正常执行。以下是问题镜像的Dockerfile：

FROM ubuntu:22.04

ENV DEBIAN_FRONTEND=noninteractive
RUN apt-get update && \
    apt-get install -qq -y \
    locales sudo python3 \
    python3-pip python3-pexpect python3-git python3-jinja2 python3-subunit \
    binutils build-essential bzip2 chrpath cpio cpp curl debianutils diffstat \
    file g++ gawk gcc git iputils-ping libacl1 libgnutls28-dev liblz4-tool \
    libtinfo5 make patch socat unzip wget xz-utils zstd zip

RUN locale-gen "en_US.UTF-8" && update-locale LANG=en_US.UTF-8

RUN useradd -m bb && \
    usermod -aG sudo bb && \
    mkdir -p /home/bb && \
    chown -R bb:bb /home/bb && \
    usermod --shell /bin/bash bb && \
    echo "bb ALL=(ALL) NOPASSWD: ALL" > /etc/sudoers.d/no_password

ENTRYPOINT exec /bin/bash -l
WORKDIR /home/bb
USER bb

请问可能的故障原因是什么，或该如何进一步调试？使用本地运行器加--debug参数也未获得更多有效信息。

核心原因 #

问题出在镜像的ENTRYPOINT配置：ENTRYPOINT exec /bin/bash -l。

• 这条配置让bash成为容器的PID 1进程。Linux系统中，PID 1进程会忽略默认的SIGTERM信号，而GitLab Runner在任务执行完成后，会发送SIGTERM信号终止容器主进程。
• 由于PID 1的bash不响应SIGTERM，Runner会超时后强制发送SIGKILL，最终判定任务失败，返回退出码1。

调试与修复方案 #

临时调试验证 #

• 在CI脚本末尾添加exit 0，强制指定任务退出码，观察是否仍失败。
• 临时修改镜像，注释掉ENTRYPOINT行，改用CMD ["/bin/bash"]，重新构建后测试CI任务。

永久修复镜像 #

根据需求选择以下两种方案：

1. 移除ENTRYPOINT，改用CMD
   去掉ENTRYPOINT exec /bin/bash -l，添加CMD ["/bin/bash"]。GitLab Runner会自动启动shell执行任务脚本，无需强制指定登录shell作为入口。
2. 保留登录shell环境的修复
   如果需要加载登录shell的配置（比如~/.bashrc），修改ENTRYPOINT为：

   ENTRYPOINT ["/bin/bash", "-l", "-c"]
   

   这样Runner传递的任务脚本会被bash正确执行，执行完成后bash会退出，返回脚本的实际退出码。

本地验证方法 #

用docker命令本地测试镜像行为：

# 运行镜像执行测试命令
docker run --rm <your-image> "ps -A; echo $?"
# 查看容器退出码
echo $?

如果退出码为0，说明镜像修复有效。

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