C++项目选基础镜像应避免ubuntu:latest等泛化镜像，优先选用gcc:11、gcc:12或ubuntu:22.04（自带GCC 11.2），确保支持C++11及以上标准；若依赖Boost需手动安装libboost-dev；慎用Alpine因musl libc与glibc差异易致线程相关静默崩溃。
直接能跑通的最小可行配置就三件事：选对镜像、写对 script、用对 stages。其他花哨功能（缓存、覆盖率、跨平台）先别碰，90% 的 C++ 项目卡在编译失败或测试不触发上。
怎么选基础镜像才不会编译报错
C++ 项目最常栽在 GCC 版本太低或缺头文件上。别用 ubuntu:latest 或 debian:stable 这类泛化镜像——它们默认带的 GCC 往往低于 7.4，不支持完整 C++11 线程池语法。
- 优先用官方构建镜像：
gcc:11、gcc:12或ubuntu:22.04（自带 GCC 11.2） - 如果项目依赖 Boost，加一行
apt-get update && apt-get install -y libboost-dev，别指望镜像里预装了所有版本 - 避免用 Alpine 镜像跑 C++ 测试——musl libc 和 glibc 行为差异会导致
std::thread或信号处理异常，尤其在线程池销毁阶段静默崩溃
test job 里 cmake + make 脚本怎么写才真正执行测试
很多配置看着有 ctest 或 ./test，但实际没跑测试——因为没指定构建产物路径，或测试可执行文件根本没生成。
- 必须显式进入构建目录：
mkdir -p build && cd build，否则cmake ..可能污染源码树 - 开启测试构建：加
-DBUILD_TESTS=ON（假设你用的是 GoogleTest 模板），否则make test是空操作 - 运行测试要带路径：
ctest --output-on-failure -C $CMAKE_BUILD_TYPE，-C参数漏掉会导致找不到测试二进制 - 别信
make test——它只是 ctest 的包装，底层还是调 ctest，直接调更可控
为什么 test job 总是跳过，或者报 “No tests were found”
这不是 CI 配置问题，是 CMakeLists.txt 和测试注册没对齐。CI 只是照单执行，它不负责发现测试逻辑。
立即学习“C++免费学习笔记（深入）”；
- 检查
add_test()是否在if(BUILD_TESTS)块内，且被正确 include 到主构建中 - GoogleTest 项目必须调用
include(GoogleTest)并用gtest_discover_tests()（CMake 3.10+），否则 ctest 看不到测试用例 - 如果用自定义 main() 启动测试，确保可执行文件名不叫
test——GitLab Runner 在某些 shell 下会和内置test命令冲突，改叫run_tests更安全 - 加
CTEST_OUTPUT_ON_FAILURE:1到 variables，让失败时输出断言详情，而不是只显示 “Failed”
build 和 test 必须分两个 job 吗
不是必须，但强烈建议。合在一个 job 里会让错误定位变困难——你不知道是编译挂了，还是测试段错误了，还是链接失败。
- build job 输出
artifacts: paths: [build/]，test job 用dependencies: [build]拉取，避免重复构建 - 如果项目小（比如单个 .cpp 文件），可以合并，但
script必须分两段写清楚：g++ -std=c++11 -o test test.cpp && ./test - 注意
before_script里别装编译器——镜像已含，重复 apt install 会拖慢流水线，还可能因锁文件冲突失败
最容易被忽略的一点：C++ 测试常依赖临时文件、共享内存或端口，而 GitLab Runner 默认以非 root 用户运行，且容器环境无 /dev/shm 支持。如果你的线程池或 IPC 测试用到了 shm_open 或 std::shared_mutex，得在 job 里加 privileged: true 或换用 docker:dind executor——但这会大幅增加安全风险，不如先改测试逻辑，避开系统级资源依赖。
