单体仓库中按需构建指定Docker镜像的Azure Pipeline配置方案

针对你在单体仓库中管理8个独立产品Docker镜像的场景，以下是几种无需拆分仓库即可实现单个产品改动仅构建对应镜像、共享代码改动全量构建的方案，同时支持手动指定构建范围：

方案1：路径触发+阶段条件判断 #

这是最常用的自动触发方案，通过路径过滤和Job条件判断，让Pipeline自动识别改动范围并执行对应构建。

配置思路 #

假设你的仓库目录结构如下：

├── shared/          # 共享代码目录
├── product-a/       # 产品A目录（含Dockerfile）
├── product-b/       # 产品B目录（含Dockerfile）
...
└── product-h/       # 产品H目录（含Dockerfile）

1. 设置触发路径：在azure-pipeline.yaml中定义触发分支和路径范围，确保只有指定目录改动时才触发Pipeline：

trigger:
  branches:
    include:
      - main
      - refs/pull/*/merge  # 覆盖PR触发场景
  paths:
    include:
      - shared/*
      - product-a/*
      - product-b/*
      - product-c/*
      - product-d/*
      - product-e/*
      - product-f/*
      - product-g/*
      - product-h/*

2. 为每个产品添加带条件的构建Job：每个产品的构建Job仅在共享代码改动或自身产品目录改动时执行：

jobs:
- job: Build_Product_A
  condition: |
    or(
      changeset.contains('shared/'),
      changeset.contains('product-a/')
    )
  steps:
  - script: docker build -t product-a:$(Build.BuildId) ./product-a
    displayName: 'Build Product A Docker Image'
  # 后续镜像推送等步骤

- job: Build_Product_B
  condition: |
    or(
      changeset.contains('shared/'),
      changeset.contains('product-b/')
    )
  steps:
  - script: docker build -t product-b:$(Build.BuildId) ./product-b
    displayName: 'Build Product B Docker Image'
  # 后续镜像推送等步骤

# 重复上述Job结构至Product H

优势 #

• 完全自动化，无需手动干预，PR或主分支推送时自动识别改动范围
• 逻辑清晰，每个Job的触发条件明确

方案2：自定义变量+手动触发标识 #

如果你需要手动指定构建范围（比如测试特定产品），可以结合自定义变量实现精准控制，同时保留自动触发的逻辑。

配置思路 #

1. 定义自定义变量：在Pipeline中添加一个名为BUILD_PRODUCTS的变量，默认值为空（或all）。手动触发Pipeline时，可指定值为单个产品（如product-a）或多个产品（如product-a,product-b）。

2. 调整Job的条件判断：每个产品的构建Job满足以下任一条件即执行：

   • 共享代码目录改动
   • 自身产品目录改动
   • 手动指定了该产品的构建

jobs:
- job: Build_Product_A
  condition: |
    or(
      changeset.contains('shared/'),
      changeset.contains('product-a/'),
      eq(variables['BUILD_PRODUCTS'], 'product-a'),
      contains(variables['BUILD_PRODUCTS'], 'product-a')
    )
  steps:
  - script: docker build -t product-a:$(Build.BuildId) ./product-a
    displayName: 'Build Product A Docker Image'

# 其他产品Job同理

优势 #

• 兼顾自动触发和手动触发场景，灵活性高
• 支持单次构建多个指定产品

方案3：模板复用+动态Job生成 #

如果8个产品的构建逻辑高度相似，可将构建逻辑抽成模板，通过模板参数动态生成Job，提升配置的可维护性。

配置思路 #

1. 创建构建模板文件：新建docker-build-template.yaml，封装通用的构建逻辑和条件判断：

parameters:
  - name: productName
    type: string
  - name: productPath
    type: string

jobs:
- job: Build_${{ parameters.productName }}
  condition: |
    or(
      changeset.contains('shared/'),
      changeset.contains('${{ parameters.productPath }}/')
    )
  steps:
  - script: docker build -t ${{ parameters.productName }}:$(Build.BuildId) ./${{ parameters.productPath }}
    displayName: 'Build ${{ parameters.productName }} Docker Image'
  # 通用的镜像推送、测试等步骤

2. 在主Pipeline中引用模板：通过模板参数快速生成所有产品的构建Job：

trigger:
  branches:
    include:
      - main
      - refs/pull/*/merge
  paths:
    include:
      - shared/*
      - product-a/*
      - product-b/*
      ...
      - product-h/*

jobs:
- template: docker-build-template.yaml
  parameters:
    productName: ProductA
    productPath: product-a

- template: docker-build-template.yaml
  parameters:
    productName: ProductB
    productPath: product-b

# 依次添加至Product H

优势 #

• 构建逻辑统一维护，修改时只需调整模板，无需逐个修改Job
• 减少重复代码，提升Pipeline配置的可读性

注意事项 #

• 路径匹配准确性：确保shared/和各产品目录的路径匹配规则正确，避免漏触发或误触发
• PR场景兼容性：Azure Pipeline在PR触发时，changeset.contains()会基于PR的改动内容进行判断，无需额外配置
• 变量优先级：手动触发时设置的变量优先级高于Pipeline默认变量，可覆盖自动触发的逻辑

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