如何实现单个GitLab CI pipeline多Runner按序执行部署任务

不存在让多个Runner顺次执行同一个job的原生配置，你的场景不需要硬套parallel matrix，通过分阶段绑定Runner专属标签的方案即可完全满足需求。

为什么parallel matrix不符合你的需求 #

• parallel matrix设计目标就是同阶段多任务并行执行，GitLab不会保证同阶段job的执行顺序，所有符合标签匹配的Runner会被同时调度拉起任务
• 每个job启动时默认拉取的是pipeline触发时的原始commit代码，并行场景下某个job内提交推送到仓库的修改，其他已经启动的job不会自动拉取，还很容易出现多job同时推代码产生的提交冲突
• 同阶段job默认要等所有实例执行完才会进入下一阶段，你在前置步骤做的文件修改既没法留存到对应部署环节，也没法按顺序同步给后续服务器的部署任务

推荐实现方案：分阶段绑定Runner专属标签 #

这是最稳定、配置成本最低的方案，完全匹配你顺次执行、修改留存推仓库的需求：

1. 先给3台绑定了不同服务器部署权限的Runner分别配置唯一标签，比如对应3台业务服务器的Runner分别打deploy-node1、deploy-node2、deploy-node3标签，确保每个标签只对应一台目标Runner
2. 把pipeline拆成3个顺序执行的阶段，每个阶段只放对应一台服务器的「配置修改->提交推送->构建->部署」全流程任务，每个任务通过tags字段强制调度到对应标签的Runner上
3. 后序阶段的任务启动时先拉取仓库最新代码，就能拿到前一台服务器部署时提交的配置修改，实现修改的顺次留存

参考配置示例：

stages:
  - deploy_node1
  - deploy_node2
  - deploy_node3

deploy_node1_task:
  stage: deploy_node1
  tags:
    - deploy-node1 # 强制调度到第一台服务器对应的Runner
  script:
    # 执行第一台服务器对应的差异化文件调整
    - sed -i 's/DEPLOY_TARGET/node1/g' ./conf/env.config
    # 提交修改推送到仓库，加[skip ci]避免推送触发新pipeline导致死循环
    - git add .
    - git -c user.name="gitlab-ci-bot" -c user.email="ci@example.com" commit -m "auto: update config for node1 deployment [skip ci]" || echo "no config change"
    - git push origin $CI_COMMIT_BRANCH
    # 执行第一台服务器的构建、部署逻辑
    - npm run build
    - bash ./deploy.sh node1

deploy_node2_task:
  stage: deploy_node2
  tags:
    - deploy-node2 # 强制调度到第二台服务器对应的Runner
  script:
    # 先拉取上一步提交的最新代码
    - git pull origin $CI_COMMIT_BRANCH
    # 执行第二台服务器对应的差异化文件调整
    - sed -i 's/DEPLOY_TARGET/node2/g' ./conf/env.config
    - git add .
    - git -c user.name="gitlab-ci-bot" -c user.email="ci@example.com" commit -m "auto: update config for node2 deployment [skip ci]" || echo "no config change"
    - git push origin $CI_COMMIT_BRANCH
    # 执行第二台服务器的构建、部署逻辑
    - npm run build
    - bash ./deploy.sh node2

deploy_node3_task:
  stage: deploy_node3
  tags:
    - deploy-node3 # 强制调度到第三台服务器对应的Runner
  script:
    - git pull origin $CI_COMMIT_BRANCH
    # 执行第三台服务器对应的差异化文件调整
    - sed -i 's/DEPLOY_TARGET/node3/g' ./conf/env.config
    - git add .
    - git -c user.name="gitlab-ci-bot" -c user.email="ci@example.com" commit -m "auto: update config for node3 deployment [skip ci]" || echo "no config change"
    - git push origin $CI_COMMIT_BRANCH
    # 执行第三台服务器的构建、部署逻辑
    - npm run build
    - bash ./deploy.sh node3

关键注意事项 #

• 所有CI内自动提交的commit信息必须携带[skip ci]标记，否则推送代码会触发新的pipeline，造成无限循环
• 提前给Runner配置的Git凭据授予对应分支的推送权限，避免push失败
• commit命令后加|| echo "no config change"是为了适配没有文件变更的场景，避免没有改动时commit命令返回非0导致job失败

可选替代方案 #

如果不想拆3个独立stage，可以用needs关键字手动指定job的依赖顺序，结合matrix和动态标签实现类似效果，但配置复杂度更高，依赖链排查问题成本高，稳定性不如分阶段方案，不推荐优先使用。
不要尝试用artifacts在job之间传递修改后的文件，artifacts仅在pipeline生命周期内临时存储，不会把改动写入Git仓库，满足不了你要把调整后的代码推送到同一仓库留存的需求。

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