[skip ci]是否适用于构建验证流水线？分支策略场景技术咨询

1. Does [skip ci] work for build validation pipelines? #

Short answer: Yes, in most mainstream CI/CD systems (like Azure DevOps, GitHub Actions, GitLab CI), [skip ci] (or similar variants like [ci skip]) can work for build validation pipelines—but with a key caveat: the tag has to be present in the commit message that triggers the pipeline.

Build validation pipelines are usually triggered by commits in a pull request (PR). If your PR's commit includes [skip ci] in its message, the corresponding build validation run will be skipped. That said, some systems might require the tag to be placed at the start or end of the message, so double-check your platform's docs if it's not working as expected.

One important note: If you've enforced build validation via branch policies, most systems will still respect the [skip ci] tag unless the policy explicitly overrides it. So it’s valid for build validation pipelines when used correctly.

2. How to implement your quality gate when [skip ci] fails for auto-pushed commits in PRs? #

I get why this is frustrating—when your pipeline auto-updates a YAML file with the new Docker tag and pushes it, the [skip ci] in that auto-commit doesn’t bypass the build validation pipeline. That’s usually because your branch policy enforces build validation for all commits to the PR branch, even auto-generated ones from your pipeline, and some systems ignore [skip ci] for policy-enforced runs.

Here are three actionable solutions tailored to your scenario:

Option 1: Skip duplicate build steps (not the entire pipeline) #

Instead of trying to skip the whole pipeline with [skip ci], add conditional logic to your build validation pipeline to skip the Docker image build step when it’s not needed. Here’s how to do it:

• When your pipeline builds the image and updates the YAML, use a specific commit message tag like [auto-tag-update] for that push.
• In your pipeline’s Docker build step, add a condition that skips the step if the triggering commit’s message contains that tag. For example, in Azure DevOps:

  - task: Docker@2
    displayName: Build Docker image
    condition: not(contains(variables['Build.SourceVersionMessage'], '[auto-tag-update]'))
    inputs:
      command: build
      repository: my-image
      tags: $(Build.SourceVersion)
  

This way, the full build validation pipeline still runs (satisfying your branch policy), but it skips the redundant image build when the YAML was just updated with the correct tag.

Option 2: Move the YAML update to a post-validation pipeline #

Separate your workflow into two parts:

1. Build validation pipeline: Focus solely on building the Docker image, running tests, and validating quality. Don’t update the YAML here.
2. Post-validation pipeline: Trigger this pipeline only when the build validation pipeline succeeds. This pipeline’s job is to update the YAML with the new tag and push the change to the PR branch. Since this push is after the build validation has already passed, you can safely add [skip ci] to the commit message—most systems will respect it here because the branch policy’s build validation requirement is already satisfied.

Option 3: Add exceptions to your branch policy #

If your CI/CD system supports it, configure your branch policy to exclude auto-generated commits from build validation. For example:

• Exclude commits from the pipeline’s service account (the identity that pushes the auto-updated YAML).
• Exclude commits with a specific message tag like [auto-tag-update].
  This way, the auto-pushed commits won’t trigger a new build validation run, while all manual commits to the PR still go through the required checks.

For your specific use case (avoiding duplicate Docker builds by updating the YAML tag), Option 1 is probably the most straightforward and reliable—it keeps everything within the build validation pipeline, satisfies your branch policy, and eliminates redundant work.

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