2
votes

I have two build definitions in Azure DevOps, one for gated check in and one for continuous integration into release. I want to use one build definition to run our GCI and our CI build so I don't have to maintain two separate build defs with similar setup, teardown, etc.

Is there a variable I can check in Azure DevOps when a build is queued to differentiate whether the build is triggered by a PR for GCI, or not? If there's a better way all ears.

2

2 Answers

1
votes

Yes! there is a variable Build.Reason:

IndividualCI: Continuous integration (CI) triggered by a Git push or a TFVC check-in.

BatchedCI: Continuous integration (CI) triggered by a Git push or a TFVC check-in, and the Batch changes was selected.

CheckInShelveset: Gated check-in trigger.

So you can in the build task add a condition to run only of the build is GCI/CI, for example (run only if the build is CI):

and(succeeded(), in(variables['Build.Reason'], 'IndividualCI', 'BatchedCI'))
0
votes

I think you can use predefined variable named Build.Reason.

Add it to Build number format and then whenever you trigger your build, you can see directly what triggers it in the build#.

For example, if your Build number format is $(date:yyyyMMdd)$(Build.Reason), then your build# will display 20190523PullRequest or other format that conform to the definition of variables.

I hope this will help you, have a good day.