1

I don't understand why can I check this two options together because this options are not similar in their behavior. I only want to check in the changes when the build (CI) succeeds. What I need to do?

Have a nice day.

Ran Nissan
  • 92
  • 1
  • 1
  • 10

1 Answers1

0

There is no impact between CI and Gated check-in. When you select CI, 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 CI triggers for committed changes check box.

Detailed information you can refer to the link below:

https://learn.microsoft.com/en-us/vsts/pipelines/build/triggers?view=vsts

Since you only want to check in the changes that builds succeed, you should only select Gated check-in.

Cece Dong - MSFT
  • 29,631
  • 1
  • 24
  • 39
  • Hey, there are differences between the gated check-in build and CI build? It is so confusing. I mean maybe the gated check in build is in the local repository. – Ran Nissan Jun 05 '18 at 13:19
  • I am not talking about the differences about their principles, I mean about the build himself. So If there is build in the gated check in, why I need to trigger CI build again (same build I think)? – Ran Nissan Jun 06 '18 at 06:16
  • There is no need to trigger CI build after gated build. They are not required to be triggered together. Someone only need CI build for a particular version control path. – Cece Dong - MSFT Jun 06 '18 at 06:38
  • Thank you for your answers, Cece Dong :) – Ran Nissan Jun 06 '18 at 10:21