0

在 TFS 2015 中，我们创建了一个 vNext (VSTS) 任务，该任务将找到一个选定的文件，替换一个标记（版本号是它开始的地方，）写出对文件的更改，并签入文件并附上注释变化的性质。它在构建过程中通过自动化完成了这一切。

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

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

到目前为止我所做的。

  1. 我为 VSTS 任务编写了一个 task.json，它接受它传递给 PowerShell 脚本的参数。

  2. 我编写了一个 PowerShell 脚本，它调用 C# 控制台应用程序来定位和更改任务指定的文件中的令牌。更改文件内容后，它会覆盖原始文件。

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

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

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

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

4

1 回答 1

0

使用 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" )

事实证明，这个练习帮助我理解了 Undetermined Workspace，我的问题 #2。

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

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

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

Set-Location $env:System_DefaultWorkingDirectory

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

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

于 2021-05-11T20:43:04.367 回答