更改项目文件并签入更改的 VSTS 任务答案

【问题标题】：VSTS Task that changes project files and checks in the changes更改项目文件并签入更改的 VSTS 任务
【发布时间】：2021-07-28 03:19:17
【问题描述】：

在 TFS 2015 中，我们创建了一个 vNext (VSTS) 任务，该任务将找到一个选定的文件，替换一个令牌（版本号是它开始的地方，）写出对文件的更改，并使用评论更改的性质。这一切都是在构建过程中通过自动化完成的。

我们即将升级到 DevOps 2020，并且不推荐使用 2015 年的 TFS 管理工具，这本身很好，但是，我们仍然需要在构建过程中自动执行这些文件更改，包括签入注意变化的性质。

直接移植旧任务惨遭失败。我已将该流程重写为 C# 控制台应用程序项目，并计划在 PowerShell 脚本期间调用它，但我遇到了许多阻碍该计划的障碍。

到目前为止我做了什么。

我为 VSTS 任务编写了一个 task.json，它接受它传递给 PowerShell 脚本的参数。
我编写了一个 PowerShell 脚本，它调用 C# 控制台应用程序来定位和更改任务指定的文件中的令牌。修改文件内容后覆盖原文件。

我似乎有两个问题，目前我无法解决。

我希望（如果任务参数规定）将管道环境变量 $env:BUILD_BUILDNUMBER 从 C# 代码更改为新值。我正在使用以下 C# 命令使用第三个参数，期望这将允许管道查看它对变量所做的更改： Environment.SetEnvironmentVariable("BUILD_BUILDNUMBER", buildNumber, EnvironmentVariableTarget.Machine ); （我也尝试不使用参数以及用户和进程，但无济于事。）该变量不会“设置”以使管道在控制台应用程序之外看到。
我需要从 C# 代码检查第 2 步中所做的更改，然后返回到带有简短注释的代码存储库。管道执行的初始“获取”调用 tf，但我没有取得同样的成功。我发现，如果我调用 VS2019 的 tf.exe 副本或构建机器上的“外部”中的代理副本，无论是从 C# 还是从后来的 PowerShell 脚本，我都会得到“##[错误]无法确定工作区。您可以通过运行 'tf workspaces /collection:TeamProjectCollectionUrl' 来纠正此问题。”不用说，稍后运行 tf 工作区的说明也无济于事。

我希望这些事情有简单的解决方案。我已经搜索过，但没有找到对 DevOps 2020 的 API 调用来检查代码。也许那不存在。至于环境变量，我对为什么 EnvironmentVariableTarget.Machine 不起作用有点神秘。我怀疑它与未调用 ##vso[] 方法有关，但我不确定如何将我的发现从控制台应用程序（也需要返回 0 表示成功，否则失败）传递给 PowerShell可以更轻松地更改变量的脚本。

如果对此有任何好主意，我将非常感谢您提供的见解。我在这方面已经有一段时间了，我不知道还需要考虑什么来完成这项工作。

【问题讨论】：

嗨@Kent，您在 TFS 2015 中使用了什么任务？在管道运行期间，您希望将更改签入到哪里？如果您想在 Azure DevOps 上签入对存储库的更改，您可以尝试使用相关命令（git command 用于 Git 存储库，tf command 用于 TFVC 存储库）来签出并检查源文件。
签入发生在构建之前，因此构建将包含这些更改。我正在使用 TFVC，正如我指出的，无论是从代理区域中的实例还是从 VS2019 中的构建机器副本调用 tf 命令，我都会收到错误消息，指出它无法确定工作区。这是我无法通过 MS 提供的 tf 工作区 /collection 解决的问题。
我已经解决了部分关于环境变量的问题。这一半的解决方案是在 C# 中将 PowerShell 作为进程调用，传入一个脚本文件，该文件将接受新版本的参数，然后运行 Write-Host("##vso[Build.UpdateBuildNumber]$newBuildNumber") 来放置它在管道中。这似乎工作得很好。所以我剩下的就是 tf 命令，它坚持认为我的工作空间无法确定。
嗨@Kent，也许您可以尝试使用命令tf workspace 在代理上创建工作区。

标签： c# powershell azure-devops azure-pipelines-tasks azure-devops-server-2020

【解决方案1】：

使用 TFVC 而不是 Git，以及许多其他小的遗留技术项目，使得在这种情况下使用新工具更难理解。

所以我的第一个问题是，在构建开始之前更新构建任务中的环境构建号。我能够从我的 C# 代码中设置变量，方法是打开一个 PowerShell 进程，该进程接受一个参数来使用 PowerShell 中的 ##vso[Build.UpdateBuildNumber] 函数更新变量。执行此操作的 C# 代码如下所示：

        var ps = @$"C:\Windows\System32\WindowsPowerShell\v1.0\PowerShell.exe";
        var script = $@"SetEnvironmentBuildNumber.ps1";
        if (File.Exists( script )){
            if ( File.Exists( ps ) )
            {
                await Task.Run( () =>
                {
                    var scriptWithArguments = string.Concat( Path.Combine( Directory.GetCurrentDirectory(), script ), " -newBuildNumber ", newBuildNumber);
                    Process.Start( ps, scriptWithArguments );

                } );
            }
            else
            {
                Console.WriteLine( $"PowerShell File Not found at: {ps}" );
            }
        }
        else
        {
            Console.WriteLine( $"The current directory is: {Directory.GetCurrentDirectory()}");
            Console.WriteLine($"Script File Not found at: {script}");
        }

SetEnvronemntBuildNumber.ps1 中的 PowerShell 脚本如下所示：

[CmdletBinding()]
param(
[string][Parameter(Mandatory=$true)]$newBuildNumber
)
Write-Host( "Setting the new build number - " + $newBuildNumber )
Write-Host( "##vso[Build.UpdateBuildNumber]$newBuildNumber" )

事实证明，这个练习帮助我理解了未确定的工作区，我的问题 #2。

如果您查看我的 C# 代码的 if 语句，您会注意到一个检查以查看当前工作目录是哪个目录。发现我的新任务将当前工作目录更改为我的任务的位置，而不是管道的工作目录，这让我有理由暂停。

尽管我脱离了 C# 代码，回到我的 PowerShell 脚本，我不是在查看解决方案的目录，而是查看任务目录。如果我从这个视图调用 tf，没有源代码，因此无法确定 WorkSpace。

解决方案很简单，可以这么说，有一个管道系统环境变量可以让我回家。如下调用 PS Set-Location，就在我调用 tf vc checkin... 之前，允许 tf 找到工作区并保存我的更改。

Set-Location $env:System_DefaultWorkingDirectory

这就是全部，所有这些调整都足够无辜，但如果没有任何关于 DevOps 管道方式的正式培训，诊断起来非常麻烦。当我们试图弄清楚如何从 TFVC 到 Git 时，我期待 DevOps 有更多的“乐趣”......我相信并不是我们所有的遗产都会看到如此重大的变化。

感谢您的建议，我希望这可以帮助其他一些被困在传统世界中并试图摆脱困境的可怜灵魂。

【讨论】：