搭建CI的过程中有多个工程的时候，一个完美的构建过程往往是子工程上的更新(push 或者是merge)触发父工程的构建，这就需要如下建立一个downstream pipeline

子仓库1 .gitlab-ci.yml

stages:
  - build
  
build_job:
    stage: build
    trigger:
        project: test_user/test_prj 
        branch: test_br
        strategy: depend

docs.gitlab triggerhttps://docs.gitlab.com/ee/ci/yaml/#trigger

trigger:声明当前job build_job是一个trigger job

project:要trigger的项目路径

branch:要trigger的项目的分支，没有这条配置会选择默认分支

strategy:trigger的策略，depend的意思是当前job的成功与否依赖downstream pipeline的执行状况

CI script脚本中拉其他工程的代码，没有实测成功

dummy_stage:
  script:
    - git clone https://gitlab-ci-token:${CI_JOB_TOKEN}@gitlab.instance/group/project.git

如果使用submodule管理多个工程的话

gitlab的help里面能查到当前版本submodule 在ci中的用法

help/ci/git_submodules.md#using-git-submodules-in-your-ci-jobs

首先要使用相对路径，配置yml可以使用variables或者script拉去submodule的代码

按照如上配置CI拉去submodule的时候仍然报如下错误，怀疑是project的private属性影响的

修改了private属性为internal依然有问题，网上搜到得解决方案是把CI拉代码得方式配置成clone就可以解决问题了

最终可以拉下来代码的yml如下，即使GIT_SUBMODULE_STRATEGY  normal效果等于script得内容，用GIT_SUBMODULE_STRATEGY也会报not a tree的错误

    variables:
        GIT_STRATEGY: clone
    script:
        - git submodule sync
        - git submodule update --init

如果ci脚本里需要执行sudo脚本的话，可以通过修改gitlab-runner配置文件来实现

ps -elf |grep gitlab
/usr/bin/gitlab-runner run --working-directory /home/gitlab-runner --config /etc/gitlab-runner/config.toml --service gitlab-runner --user gitlab-runner

sudo service gitlab-runner stop
sudo vim /etc/systemd/system/gitlab-runner.service
--user gitlab-runner -->  --user root
sudo systemctl daemon-reload
sudo service gitlab-runner start

ps -elf |grep gitlab
/usr/bin/gitlab-runner run --working-directory /home/gitlab-runner --config /etc/gitlab-runner/config.toml --service gitlab-runner --user root