在TFS 2015升级3之后，我们的一些构建开始记录奇怪的日志行。如下所示，所有'a'字符都替换为8个星号字符。
2016-08-08T07：58：01.0425923Z检查******** rtif ******** cts 目录存在：d：\ b2 \ 10 ******** 2016-08-08T07：58：01.0425923Z 删除******** rtif ******** cts目录。 2016-08-08T07：58：01.0582131Z Cre ******** ting ******** rtif ******** cts 目录。 2016-08-08T07：58：01.0582131Z检查测试结果 目录存在：d：\ b2 \ 10 \ TestResults 2016-08-08T07：58：01.0738385Z 删除测试结果目录。 2016-08-08T07：58：01.0738385Z Cre ******** ting测试结果目录。 2016-08-08T07：58：01.1675919Z St ******** rting：获取来源2016-08-08T07：58：01.1832163Z进入 TfvcSourceProvider.Prep ******** reRepositoryAsync 2016-08-08T07：58：01.1832163Z loc ******** lP ******** th = d：\ b2 \ 10 \ s 2016-08-08T07：58：01.1832163Z cle ******** n = True 2016-08-08T07：58：01.1832163Z sourceVersion = 15137
代理的“_diag”文件夹中的日志文件也包含带星号的这些行。我们试图分析正常日志记录版本和这些奇怪版本之间的差异，但我们没有发现任何明显的差异。我们尝试克隆这些构建，但克隆的构建也以这种方式记录。如果我们创建了一个新的构建，它也会记录这些星号。
有没有人经历过同样的行为？
答案 0 :(得分：1)
如果您创建（有意或无意克隆）包含单个字母的安全变量（在您的情况下＆＃39; a＆＃39;），就会发生这种情况。该版本将通过＆＃39; **********＆＃39;替换日志中的那个字母。因为它认为它是一个不应该写入日志的安全变量。
答案 1 :(得分：0)
最后我发现了错误。这是Update 3中的新功能。我们有一个私有nuget服务器，它作为通用服务端点添加到TFS。在旧TFS中，您必须为每项服务提供用户名和密码，您不能将密码留空。所以我们把一个＆＃39; a＆＃39;在里面。在更新3之前，这不是一个问题。但是更新3从该密码创建了一个安全变量，这就是日志搞砸的原因。