Paths that are cloaked will not be pulled into the local workspace during a GET
from TFS or VSTS.
Check-ins that contain files only in cloaked folders (in other words, fully cloaked)
will not trigger a build,
whereas a check-in containing any path that isn't cloaked will trigger a build.
For example, suppose the Project path is $/Example/project/path, and the repository contains the following subfolders:
$/Example/project/path/ANow, suppose the following paths were entered as Cloaked Paths:
$/Example/project/path/A/1
$/Example/project/path/A/2
$/Example/project/path/B
$/Example/project/path/C
$/Example/project/path/A/2...then the resulting workspace on the Jenkins server would only have the following folders:
$/Example/project/path/B
$/Example/project/path/A
$/Example/project/path/A/1
$/Example/project/path/C
To continue with the example, the following check-in will not trigger a build, because it only contains changes under cloaked paths:
$/Example/project/path/A/2/alpha.txt...whereas this check-in will trigger a build, because it contains at least one path that isn't cloaked:
$/Example/project/path/A/2/second.txt
$/Example/project/path/B/bravo.txt
$/Example/project/path/A/1/first.txt
$/Example/project/path/A/2/second.txt
$/Example/project/path/B/bravo.txt