CODEWITHSUNDEEP
azure-devopsazure-pipelinesazure-pipelines-yaml
Pat Long - Munkii Yebee
Pat Long - Munkii Yebee

Reputation: 3639

Preventing CI triggering when and Build Validation policy build also running (Azure Dev Ops)

We have a YAML based pipeline that Unit Tests and build an ASP NET Core website then if everything is OK it deploys to DEV, TEST and eventually Live Azure Resources.

Our source control is Git within Azure Dev Ops.

Our process has us working in a branch for each feature, once those branches are ready we merge them into a "release" branch for an integration test before being PR'ed to MAIN. An example of our release branch would be "release_3_1_5".

The start of the YAML pipeline looks like this

pool:
  vmImage: 'windows-latest'

# Why would I want 'resources'
# resources:
#  pipelines:
#  - pipeline: 
   
variables:
  azureSubscriptionEndpoint: 'ARM Service Connection'
  webAppKind: webApp
  solution: '**/*.sln'
  buildPlatform: 'Any CPU'
  buildConfiguration: 'Release'
  # Change this when adding functionality that is a breaking change
  majorVersion: 3
  # Change this when adding functionality that is backwards compatible  
  minorVersion: 1
  # Change this when making fixes that are backwards compatible and not adding functionality
  buildVersion: 0
  # Concatenate version parts and buildId to get a full build version string
  fullBuildVersionString: $(majorVersion).$(minorVersion).$(buildVersion).$(Build.BuildID)
  
name: $(MajorVersion).$(MinorVersion).$(buildVersion).$(Build.BuildID)
  
stages:
- stage: Build
  jobs:
  - job: Build_Job
    steps:
    - bash: |
        echo $(fullBuildVersionString)

We don't specify any explicit triggers so the build runs everytime we push to a branch.

The "MAIN" branch has some branch policies set, those policies include "Build Validation" and currently the Build Validation build policy is configured to run the same YAML pipeline.

The CI pipeline works just fine when pushing changes to our branches, except when the branch in question is the subject\source of a PR to MAIN. In this situation the pipeline starts twice. Once for the push to the "release" branch and once by the branch policy because of the PR into MAIN.

Is there a better way to configure the pipeline so it does not kick off twice? I basically do not want the CI truigger to fire when the branch is the source of a PR to MAIN but that looks like an impossible condition

Upvotes: 1

Views: 889

Answers (1)

Derek Williams
Derek Williams

Reputation: 550

This is something we struggle with as well. We have just accepted the double builds for now. However, I am starting to consider not having a build trigger for feature/ branches and only trigger for PRs.

The only other option are double manifests. One manifest for branches that are not MAIN, and the other being a manifest that includes only PRs and the MAIN branch.

If you want builds to run for branches, you could consider pre-receive hooks that requires builds to run locally.

Upvotes: 0

Related Questions