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

如何解决更改项目文件并签入更改的 VSTS 任务

在 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 ); （我也试过不带参数以及用户和进程，但无济于事。）该变量不会“设置”以让管道在控制台应用程序之外看到。
我需要检查在第 2 步中对 C# 代码所做的更改，并用简短的注释返回到代码存储库中。管道调用 tf 的初始“Get”，但我没有取得同样的成功。我发现，如果我调用 VS2019 的 tf.exe 副本或构建机器上“externals”中的代理副本，无论是从 C# 还是从更高版本的 PowerShell 脚本，我都会收到“##[错误]无法确定工作区。您可以通过运行 'tf workspaces /collection:TeamProjectCollectionUrl' 来更正此问题。不用说，后面运行 tf 工作空间的说明无济于事。

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

如果有关于此的任何好主意，我将非常感谢您提供的见解。我已经在这方面工作了一段时间，但我不知道还有什么要考虑才能使这项工作顺利进行。

解决方法

使用 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 脚本，我也没有查看解决方案的目录，我查看的是 Task 目录。如果我从该视图调用 tf，则没有源代码，因此无法确定工作区。

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

Set-Location $env:System_DefaultWorkingDirectory

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

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