AWS CodePipeline末阶段无法使用Source输入工件问题咨询

核心规则说明 #

CodePipeline 原生限制为：非Source阶段的直接下游阶段，无法直接跨阶段引用Source阶段的输出产物，这个是平台的固定设计，不是配置操作错误。

场景标准处理方案 #

针对你需要在Test阶段使用原始Source源码的需求，有两种合规的标准实现方式：

• 方案1：Build阶段配置双输出产物（适配Test必须在Build之后执行的场景）
  不需要调整现有流水线阶段顺序，只需要修改Build阶段对应的CodeBuild配置：
  1. 在buildspec.yml中新增次级产物配置，将原始源码目录标记为独立的次级输出，可按需排除node_modules、构建缓存等无用目录减小产物体积
  2. 在CodePipeline的Test阶段输入配置中，选择Build阶段输出的这个源码次级产物作为输入即可，原有构建产物的输出逻辑完全不需要改动
     参考配置示例：

  version: 0.2
  phases:
    build:
      commands:
        # 保留原有构建逻辑即可
        - npm run build
  artifacts:
    files:
      - dist/**/*
    name: build-output
    secondary-artifacts:
      source-copy:
        files:
          - "**/*"
        exclude-paths:
          - "node_modules/**/*"
          - ".git/**/*"
  

• 方案2：调整阶段为并行执行（适配Test不需要依赖Build产物的场景）
  如果你的Test任务只需要原始源码、不需要等待构建完成，可以直接把Build和Test两个CodeBuild action放在Source阶段之后的同一个阶段内并行执行，两个action都直接引用Source阶段的输出作为输入——这种配置完全符合CodePipeline的规则，因为两个action都属于Source的直接下游，还能缩短整体流水线的运行时长。

关于Source阶段完成后直接运行测试的说明 #

完全支持，除了上面说的并行阶段配置方式，你也可以直接把Test阶段放在Source阶段之后作为第二个阶段，Build阶段放在Test之后，只要Test是Source的直接下游，就可以正常引用Source产物，具体顺序可以根据你的任务依赖关系调整。

避坑提示：不要在Test阶段通过git clone等方式重新拉取GitHub源码绕开产物限制，这种做法会导致流水线执行的代码版本和Source阶段锁定的版本不一致，出现版本漂移，无法满足CI/CD流程的可追溯要求，属于不推荐的反模式。

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