GitLab CI手动发布作业复用Prepare依赖的优化技术问询

我明白你的痛点了——不想让Prepare在非主分支自动执行浪费资源，同时手动发布非主分支时又得用上Prepare的产物，还得兼顾不同Runner的要求。之前用<<:合并两个模板失败，主要是YAML的语法限制（同一个映射不能重复用合并标记），加上单个作业没法同时绑定Docker和Shell Runner。下面给你一套可行的解决方案：

1. 先梳理独立的作业模板 #

首先把Prepare和Publish的核心逻辑拆成独立模板，方便后续复用：

# Prepare阶段模板（绑定Docker Runner）
.prepare-docker:
  stage: prepare
  tags:
    - docker-runner  # 替换成你的Docker Runner标签
  script:
    - # 这里写Prepare的具体命令，比如构建镜像、生成发布产物等
  artifacts:
    paths:
      - ./your-build-artifacts/  # 定义产物路径，供后续作业调用

# Publish阶段模板（绑定Shell Runner）
.build-and-publish:
  stage: publish
  tags:
    - shell-runner  # 替换成你的Shell Runner标签
  script:
    - # 这里写Publish的具体命令，比如推送镜像、发布到仓库等

2. 配置develop/master分支的自动流水线 #

保留原有的自动执行逻辑，只在主分支触发：

# 自动执行的Prepare（仅develop/master分支）
prepare-artifact-auto:
  extends: .prepare-docker
  rules:
    - if: '$CI_COMMIT_REF_NAME == $DEVELOP_BRANCH || $CI_COMMIT_REF_NAME == $MASTER_BRANCH'
      when: on_success

# 自动执行的Publish（依赖自动Prepare的产物）
build-and-publish-auto:
  extends: .build-and-publish
  needs: [prepare-artifact-auto]
  rules:
    - if: '$CI_COMMIT_REF_NAME == $DEVELOP_BRANCH || $CI_COMMIT_REF_NAME == $MASTER_BRANCH'
      when: on_success

3. 配置非主分支的手动发布作业 #

把手动发布拆成两个关联的手动作业，确保只有你手动触发时才会跑Prepare：

# 手动触发的Prepare（仅非主分支，必须手动启动）
manual-prepare-artifact:
  extends: .prepare-docker
  rules:
    - if: '$CI_COMMIT_REF_NAME != $DEVELOP_BRANCH && $CI_COMMIT_REF_NAME != $MASTER_BRANCH'
      when: manual
      allow_failure: false  # 必须执行成功才能触发后续的Publish

# 手动触发的Publish（依赖手动Prepare的产物）
build-and-publish-manual:
  extends: .build-and-publish
  needs: [manual-prepare-artifact]
  rules:
    - if: '$CI_COMMIT_REF_NAME != $DEVELOP_BRANCH && $CI_COMMIT_REF_NAME != $MASTER_BRANCH'
      when: manual

4. 最后确认流水线阶段顺序 #

确保你的阶段定义覆盖所有作业：

stages:
  - test
  - prepare
  - publish

为什么这能解决你的问题？ #

• 避免资源浪费：非主分支的Prepare作业只有手动触发才会运行，完全不会自动执行，完美解决了之前用needs导致Prepare自动跑的问题。
• Runner隔离：手动Prepare和手动Publish分别绑定对应的Runner标签，满足你“不同作业用不同Runner”的要求。
• 产物复用：手动Publish通过needs依赖手动Prepare的产物，确保发布时能获取到最新的构建结果。
• 模板复用：用extends关键字复用模板逻辑，比<<:更灵活，还能避免YAML的合并冲突问题。

内容的提问来源于stack exchange，提问作者gervais.b