如何获取从 Azure Devops / VSTS / TFS 中的“Windows 机器文件复制”任务复制的文件总数？

Posted 2023-03-22

【中文标题】如何获取从 Azure Devops / VSTS / TFS 中的“Windows 机器文件复制”任务复制的文件总数？

【英文标题】：How to harvest the total number of files copied from "Windows Machine File Copy" task in Azure Devops / VSTS / TFS?

【发布时间】：2020-04-05 23:59:29

【问题描述】：

我首先要说我不知道​​这是否可能，但我希望是的。

我在 Azure Devops 中有几份工作，运行“Windows 机器文件复制”任务。 Documentation here.

在任务日志的末尾，有一个显示文件总数的输出...

2019-12-06T20:42:33.2991058Z ------------------------------------------------------------------------------
2019-12-06T20:42:33.2992182Z 
2019-12-06T20:42:33.2994274Z                Total    Copied   Skipped  Mismatch    FAILED    Extras
2019-12-06T20:42:33.2995919Z     Dirs :        29        28         0         0         0         0
2019-12-06T20:42:33.2997487Z    Files :       361       361         0         0         0         0
2019-12-06T20:42:33.2999056Z    Bytes :   89.96 m   89.96 m         0         0         0         0
2019-12-06T20:42:33.3000612Z    Times :   0:00:03   0:00:02                       0:00:00   0:00:00
2019-12-06T20:42:33.3000997Z 
2019-12-06T20:42:33.3002124Z 
2019-12-06T20:42:33.3003761Z    Speed :            31614545 Bytes/sec.
2019-12-06T20:42:33.3005534Z    Speed :            1808.998 MegaBytes/min.
2019-12-06T20:42:33.3006054Z    Ended : Friday, December 6, 2019 2:42:33 PM
2019-12-06T20:42:33.3006989Z 
2019-12-06T20:42:33.3049176Z Copying recursively from...

这个值是否作为变量存储在任何地方？有没有人能够使用这样的日志以编程方式解析来自它们的信息？

【问题讨论】：

您希望如何处理这些信息？为什么它很重要？

头发尖尖的人希望将其作为报告中的指标。随着应用程序的构建/部署自动化并迁移到云端，他们想要进行比较。

部署的文件数量作为任何指标都是毫无意义的。这需要进行沟通，以便他们可以决定一个真正衡量有用的指标。​​

是的。这对工程师来说毫无意义。然而，管理层和审计师目前不同意。

【参考方案1】：

同意 Daniel 的任命，这对开发人员来说似乎毫无意义。但是，如果有人想要这些数据，当然可以对其进行解析。

首先，我们需要知道这个任务是基于什么编译的。我们已经在 github 上开放了这个任务的源代码：WindowsMachineFileCopyV2。可以看到这个任务是使用RoboCopy来实现文件的复制。

所以，现在，您的难题可以考虑为如何读取 Robocopy 输出并将其存储为变量。

---

我想你已经知道，似乎没有办法直接对这个任务输出进行任何操作。因此，首先，您可以在此 Windows 机器复制文件任务的参数中指定 /log:file path。

日志如下所示：

目前，解析出确切的值并将其存储到变量中是非常容易的。只需编写一个脚本来读出值并存储它。我曾经提供过类似的solution，关于如何从 shell 输出中编译出值。

另外，您可以查看此script 以获取更多参考。

## Create Powershell object to tally Robocopy results
$row = "" |select COPIED, MISMATCH, FAILED, EXTRAS
$row.COPIED = [int](($robo_arr[1] -split "\s+")[4]) + [int](($robo_arr[2] -split "\s+")[4])
$row.MISMATCH = [int](($robo_arr[1] -split "\s+")[6]) + [int](($robo_arr[2] -split "\s+")[6])
$row.FAILED = [int](($robo_arr[1] -split "\s+")[7]) + [int](($robo_arr[2] -split "\s+")[7])
$row.EXTRAS = [int](($robo_arr[1] -split "\s+")[8]) + [int](($robo_arr[2] -split "\s+")[8])

【讨论】：

@nuprap。如果在编写此编译脚本时需要任何帮助，请找我。我可以提供更多。

这很棒。谢谢你。我会把它带入我的测试中。非常感谢！

@nuprap。欢迎:-)

【参考方案2】：

您可能会编写一些使用REST APIs 来检索发布日志的内容。或者您可以只查看$(System.DefaultWorkingDirectory) 中的文件数。

但我会强烈反对这个指标，因为它完全没有意义。不只是对开发人员。给大家。审核员、经理、开发人员、QA 测试人员；选择一个角色，对那个角色的人来说毫无意义。无论他们认为这是在衡量什么，它都不是在衡量那个东西。

如果这个想法是要衡量发布背后的“规模”或风险，那是完全错误的；一个大的更改可能涉及很少的文件（甚至删除个文件），而一个小的更改仍然可以覆盖大量的文件。

事实上，您最有可能看到的是，每个文件都会在每次运行发布时更新，因为时间戳不同； robocopy 不对 CRC/哈希值进行操作，它对时间戳进行操作。所以你真正发现的是文件数量是增加还是减少。这同样毫无意义，也没有衡量任何有价值的东西。

【讨论】：

我完全同意。但有时我必须在公司转型时选择我的战斗。这是他们现在已经深陷其中的一个。谢谢（你的）信息。我会检查一下。谢谢丹尼尔！