从 CI 到生产 Nuget 源的 Nuget 包版本控制和推广

Posted 2023-02-19

【中文标题】从 CI 到生产 Nuget 源的 Nuget 包版本控制和推广

【英文标题】：Nuget Package Versioning & promoting from CI to Production Nuget feeds

【发布时间】：2018-04-16 17:03:24

【问题描述】：

技术：

Proget - Nuget 包管理服务器

TFS – 内部部署 2017 更新 1

问题： 从 TFS 版本重新发布构建时，要重新打包已经进入我的 Proget 开发提要的 CI Nuget 包，似乎没有办法自动获得Semantic versioning。 关于在 Nuget 打包程序设置中设置版本出现的帮助对话框如下。

使用日期和时间 如果您选择“使用日期和时间”，这将 生成格式为 X.Y.Z-ci-datetime 的符合 SemVer 的版本 您可以在其中选择 X、Y 和 Z。

使用环境变量如果您选择“使用环境 变量'，您必须选择一个环境变量并确保它 包含您要使用的版本号。

使用内部版本号 如果您选择“使用内部版本号”，这将 使用内部版本号来打包您的版本。注意：在通用设置下 构建格式是 '$(BuildDefinitionName)_$(Year:yyyy).$(Month).$(DayOfMonth)$(Rev:.r)

我希望能够重新发布一个 Nuget 包，该包已经从我在 TFS 中的 CI 构建到我的 Proget 开发提要，再到我的生产 Proget 提要。 Microsoft 在Versioning NuGet packages in a continuous delivery world 上有一篇很棒的文章。在那篇文章中，他们回避了这样一个事实，即他们正在做类似的事情，但他们没有为如何完成提供任何真正的方向。

问题：

如何配置 Nuget 打包程序，以便在创建包时输入构建变量？或者有没有一种方法可以设置主要版本并且每次只增加次要版本？其他人如何处理从开发到生产的软件包推广？

已尝试以下方法：

尝试将 $(Version) 作为构建和发布变量，但它似乎不起作用。包裹被标记日期。此外，这似乎只在 TFS 的构建部分中真正起作用，其中模式窗口包含修改此值的点。

尝试使用日期和时间方法，并将 CI 粘贴到内部版本号中。这几乎正​​是我们想要减去 CI 定义的结果。因为是自动插入CI，所以不适合生产。

将其关闭并从 Nuspec 中提取版本，但这会假设在您的 CI 构建中，您总是在推送最后一个发布版本后将版本号提高到比当前版本高一个。这是因为 nuspec 位于您通过 TFS 发布链重新发布的构建文件中。至少可以说令人困惑。

使用设置为 $(BuildDefinitionName)$(Year:yyyy).$(Month).$(DayOfMonth)$(Rev:.r) 的内部版本号我想要的是 $(Major) .$（次要）.$（补丁）。尝试使用 1.0.0 版本的 $(Version)$ 会得到一个名为 的文件，该文件以 2017.11.3.1 作为输出，似乎忽略了 $(Version) 变量。

【参考方案1】：

不确定我是否完全明白你的意思，似乎你想在 TFS 上的 ci 进程之后创建一个语义版本化的 nupkg。

通常 nupkg 应该如图所示 MSVersioningSample: 1.0.8-ci-20171106-156033.nupkg

但是您想重命名 nupgk 并将其重新发布到 nuget 服务器作为发布版本只需 MSVersioningSample：1.0.8.nupkg 与 $(Major).$(Minor).$(Patch) 相同。

你需要在build agent中编辑NuGetPackager.ps1，修改$VersionRegex的值，详细可以看看这个问题的答案：How do I get TFS 2015 to parse 3 digit versioning for NuGet packaging

还可以尝试使用一些 3-rd 方扩展来处理 TFS 构建、发布任务、nuget 包中的语义版本控制，供您参考的示例：Semantic Versioning Build and Release Tasks

除了说明：Semantic Versioning 2.0.0 仅支持 NuGet 4.3.0+ 和 Visual Studio 2017 版本 15.3+。

【讨论】：

事实证明我们几乎可以做我们想做的事，但这仍然是一个巨大的痛苦。我们正在恢复使用解决方案文件中的后期构建过程来触发我们对生产包源的构建。

@GetFuzzy 很高兴听到这个消息，在解决方案中使用后期构建过程可能有点复杂和麻烦，但很有效。一旦你得到一个完整的解决方案，你可以在这里分享。

您可以关闭自动版本控制，只需在 PACK 命令中提供这个额外的参数。 Version=1.0.$(Build.BuildId)

如果 dotnet pack 任务有一个版本的输出变量会很好，现在它需要大量的前期工作才能在内部版本号中设置一个变量并使用该内部版本号。自动包版本控制无效。索引源和发布符号集成任务怎么样？它也需要一个版本...