GitLab付费版特性分支下父子CI/CD构建配置咨询

针对你提到的两类嵌入式项目场景，以下是可落地的实现步骤与优化建议：

1. 子项目触发父项目流水线 #

在子项目的 .gitlab-ci.yml 中添加触发逻辑，仅当推送 feature/ 前缀的特性分支时，触发父项目流水线并传递关键变量：

trigger_top_pipeline:
  stage: post_push
  rules:
    - if: '$CI_COMMIT_BRANCH =~ /^feature\/.+$/'
  trigger:
    project: your-group/top-project # 替换为父项目的完整路径
    branch: main # 父项目以默认分支启动流水线
    variables:
      TRIGGERED_SUB_PROJ: $CI_PROJECT_PATH # 触发本次构建的子项目路径
      TRIGGERED_BRANCH: $CI_COMMIT_BRANCH # 触发的特性分支名

2. 父项目拉取对应分支代码 #

父项目需要拉取自身默认分支代码，同时将触发的子项目切换到指定特性分支，其他子项目保持默认分支。推荐两种方案：

方案A：Git Submodules（依赖关系固定时优先选） #

提前在父项目中配置所有子项目为 submodule，流水线中初始化并切换目标分支：

prepare_code:
  stage: prepare
  script:
    # 初始化所有子模块，拉取默认分支
    git submodule update --init --recursive
    # 切换触发的子项目到特性分支
    cd ./path/to/${TRIGGERED_SUB_PROJ_NAME} # 替换为子项目在父项目中的本地路径
    git checkout $TRIGGERED_BRANCH
    git pull origin $TRIGGERED_BRANCH

注：需确保 Runner 拥有所有子项目的访问权限，GitLab 自动通过 CI_JOB_TOKEN 授权跨项目访问。

方案B：手动克隆（子项目动态调整时用） #

若不使用 submodule，直接在流水线中批量克隆子项目，针对触发的子项目拉取指定分支：

prepare_code:
  stage: prepare
  script:
    - |
      # 定义所有子项目的仓库路径与本地存储路径
      SUB_PROJS=(
        "your-group/kernel ./submodules/kernel"
        "your-group/u-boot ./submodules/u-boot"
        # 补充其他子项目...
      )
      for item in "${SUB_PROJS[@]}"; do
        REPO=$(echo $item | cut -d' ' -f1)
        LOCAL_PATH=$(echo $item | cut -d' ' -f2)
        if [ "$REPO" == "$TRIGGERED_SUB_PROJ" ]; then
          # 触发的子项目拉特性分支
          git clone --branch $TRIGGERED_BRANCH https://gitlab-ci-token:${CI_JOB_TOKEN}@your-gitlab-domain/$REPO.git $LOCAL_PATH
        else
          # 其他子项目拉默认分支
          git clone https://gitlab-ci-token:${CI_JOB_TOKEN}@your-gitlab-domain/$REPO.git $LOCAL_PATH
        fi
      done

3. 顶层构建与自动化测试 #

父项目流水线中依次执行构建与测试，测试阶段需绑定带有硬件设备的 Runner：

build:
  stage: build
  script:
    ./top-build.sh # 执行顶层构建脚本
  artifacts:
    paths:
      - ./output/ # 保存构建产物供测试阶段使用
    expire_in: 1d

test:
  stage: test
  tags:
    - embedded-runner # 绑定带JTAG/板卡的Runner标签
  script:
    # 执行JTAG烧录
    ./flash-jtag.sh ./output/firmware.bin
    # 板卡重启
    ./reset-board.sh
    # 运行Python单元测试
    python3 ./test-suite.py
  rules:
    - if: '$TRIGGERED_SUB_PROJ && $TRIGGERED_BRANCH' # 仅子项目触发的流水线执行测试

4. 合并权限控制（测试通过后允许合并） #

通过 GitLab 的合并请求规则实现“测试通过才可合并”：

1. 在子项目的「设置」→「合并请求」→「审批规则」中，添加**“流水线必须成功”**作为合并的必需条件；
2. 若需关联父项目流水线状态，可在子项目的合并请求流水线中添加检查步骤：

verify_top_pipeline:
  stage: verify
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
  script:
    # 查询父项目对应流水线的状态，确保成功
    curl --header "PRIVATE-TOKEN: ${GITLAB_API_TOKEN}" "https://your-gitlab-domain/api/v4/projects/${TOP_PROJECT_ID}/pipelines?ref=main&variables[TRIGGERED_SUB_PROJ]=${CI_PROJECT_PATH}&variables[TRIGGERED_BRANCH]=${CI_COMMIT_BRANCH}" | jq '.[] | select(.status == "success")'

注：GITLAB_API_TOKEN 需在子项目的「设置」→「CI/CD」→「变量」中加密存储，授予项目流水线读取权限。

5. 两类场景的针对性优化 #

场景1：XILINX Linux 构建（20个子项目） #

• 缓存编译产物：对 Kernel、UBOOT 等大体积子项目的编译目录配置 GitLab CI 缓存，减少重复编译时间：

  cache:
    paths:
      - ./submodules/kernel/build/
      - ./submodules/u-boot/build/
      # 补充其他子项目的编译路径
  

• 并行拉取子项目：将子项目克隆拆分为多个并行任务，缩短准备阶段耗时；
• 增量构建：修改顶层构建脚本，仅重新编译触发子项目的变更文件。

场景2：CortexM3/STM32 项目（5个子项目） #

• 预构建工具链镜像：制作包含 ARM GCC、JTAG 驱动的 Docker 镜像，Runner 直接使用该镜像，避免每次安装依赖；
• 测试脚本封装：将烧录、重启、测试步骤封装为可复用脚本，确保流程完全自动化；
• 小粒度提交：鼓励开发者拆分特性为小提交，加快流水线执行与问题定位。

6. 权限与安全注意事项 #

• 依赖 CI_JOB_TOKEN 实现跨项目代码拉取，无需额外配置个人令牌；
• 通过 rules 限制仅 feature/ 分支触发父项目流水线，避免无效构建；
• 所有敏感变量（如 API 令牌）需加密存储，禁止明文写入配置文件。

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