如何配置DevOps CI pipeline禁止pre release build执行publish操作

核心逻辑是给构建流程增加事件、分支过滤规则，只有代码合并到目标分支后的正式构建才执行artifacts发布操作，PR触发的前置校验构建全程跳过publish步骤，避免误触发CD发布流程。

方案1：CI步骤加触发条件（成本最低，适配绝大多数场景） #

直接在现有CI流水线的publish步骤上增加触发条件，仅匹配合并后的事件才执行该步骤：

• 先把流水线划分为两个逻辑阶段：
  • 校验阶段：所有PR事件、分支临时push事件都会触发，仅执行单元测试、代码规范检查、编译校验等前置检查逻辑，完全不涉及artifacts publish操作
  • 发布阶段：仅当触发源是「代码合并到主分支/正式发布分支（如main、release/*）的push事件」时才触发，构建完成后执行artifacts publish操作
• 主流CI工具的配置参考（可根据自己使用的工具调整对应语法）：
  • GitHub Actions：给publish步骤添加条件判断 if: github.event_name == 'push' && github.ref == 'refs/heads/main'
  • GitLab CI：给publish对应的job添加rules规则 rules: - if: $CI_COMMIT_BRANCH == "main" && $CI_PIPELINE_SOURCE == "push"
  • Azure DevOps：给publish任务添加自定义执行条件 and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/main'), eq(variables['Build.Reason'], 'IndividualCI'))

如果你的团队用的是多管道拆分架构，可以直接把PR校验和正式构建拆成两个独立流水线：PR校验流水线完全不配置publish相关步骤，只有合并后触发的正式构建流水线才配置publish逻辑，隔离更彻底，基本不会出现误触发问题。

方案2：通过artifacts标记过滤CD触发规则 #

如果你的CD流水线是监听所有artifacts发布事件触发，不想改现有CI流程的话可以调整CD触发逻辑：

• 给PR前置构建产出的artifacts打上pr-check之类的非正式标记，正式合并后构建的artifacts打上official-release标记
• 修改CD流水线的触发规则，仅监听标记为official-release的artifacts发布事件，忽略其他标记的artifacts，也可以避免PR构建误触发发布。

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