What is the exact use of Run continuous integration triggers for committed changes and other features in TFS 2017 Gated Build?

1
votes

I am bit confused with the options that are provided in the TFS 2017 Build under the Triggers section. I have a two separate build definitions one is used for code check-in i.e. called Gated Build and other is Manual build which we used for code drop\deployment on our CI servers after the Gated build is completed.

Recently, we thought of using the Gated build definitions directly for code drop which will save time in triggering the manual builds separately. However, while doing this POC I am confused with use of different features that are available in the Triggers section, especially the Run continuous integration triggers for committed changes

I have linked Gated Build with the Release Definition directly which deploys the code once the gated build is completed. I have selected both the options in the build i.e. Use workspace mapping for filters and the Run continuous integration triggers for committed changes. With this whenever I check-in the code the build once completed triggers the Release definition and deploys the code on the server but when I deselect the Run continuous integration triggers for committed changes and check-in an code it still deploys the code just because it is linked with the Release definition.

I searched on google and tried to understand the use of it and other feature but didn't understood much, I went through the link as well just got to know it won't display the NO CI in the change-set.

Can anyone please explain the exact use of each features\option present under the triggers except the Scheduled one or please let me know if there are any other links, blogs, video's tutorial any one aware of where all the features present under trigger options are explained in depth with examples?enter image description here

Enabled the Continuous integration option in CI build due to which it gets automatically triggered after the gated build is completed. enter image description here

1
tfsbuildazure-pipelines-release-pipelineazure-pipelines-build-taskgated-checkinbuild-triggers

1 Answers

1
votes

Just as literal meaning, it is used for Continuous integration.

  • For normal CI build, it will build whenever someone checks in code, it happens after the changes have been checked in to TFS.
  • If you select Gated check-in, it will accept check-ins only if the submitted changes merge and build successfully, which means only the build succeeded the changes can be checked in.

By default, CI builds are not run after the gated check-in process is complete and the changes are checked in. However, if you do want CI builds to run after a gated check-in, select the Run continuous integration triggers for committed changes check box.

More detailed information about all triggers you can refer to our official link below:

https://docs.microsoft.com/en-us/azure/devops/pipelines/build/triggers?view=azure-devops

To conclude, uncheck that option to prevent triggering the continuous integration build.

As for why check-in an code it still deploys the code just because it is linked with the Release definition. This trigger only control your build definition/pipeline, not affect release pipeline.

There is also corresponding Release Trigger. You should double check it in your environment.

For a sample about the usage of Gated Build in Azure DevOps, you could refer this blog-- Gated Check-ins in Visual Studio Team Services using TFSVC and Git