Azure Pipeline Nuget 包版本控制方案，如何获取“1.0.$(Rev:r)”

Question

我正在设置一个 Azure Pipelines 构建，它需要将 C# .NET 类库打包到 NuGet 包中。

在this documentation 中，它列出了几种自动生成 SemVer 字符串的不同方法。特别是，我想实现这个：

$(Major).$(Minor).$(rev:.r)，其中Major 和Minor 是两个变量 在构建管道中定义。这种格式会自动 使用新补丁增加内部版本号和软件包版本 数字。它将保持主要和次要版本不变，直到您 在构建管道中手动更改它们。

但这就是他们所说的，没有提供任何例子。一个了解更多信息的链接会将您带到this documentation，上面写着：

对于byBuildNumber，版本将设置为内部版本号，确保 您的内部版本号是正确的 SemVer，例如1.0.$(Rev:r)。如果你 选择byBuildNumber，任务会提取一个虚线版本，1.2.3.4 并仅使用它，丢弃任何标签。要按原样使用内部版本号， 您应该如上所述使用 byEnvVar，并设置环境 变量为BUILD_BUILDNUMBER。

同样，没有提供示例。看起来我想使用versioningScheme: byBuildNumber，但我不太确定如何设置内部版本号，我认为它从BUILD_BUILDNUMBER 环境变量中提取它，但我找不到设置环境变量的方法, 只有脚本变量。此外，我想将其设置为1.0.$(Rev:r)，还是$(Major).$(Minor).$(rev:.r)？恐怕这只会按字面意思解释。

用谷歌搜索文字字符串“versioningScheme: byBuildNumber”会返回一个结果...有没有人有使用此版本控制方案的azure-pipelines.yml？

Answer 1

byBuildNumber 使用您在 YAML 中通过 name 字段定义的内部版本号。

例如：name: $(Build.DefinitionName)-$(date:yyyyMMdd)$(rev:.r)

因此，如果您将构建格式设置为 name: 1.0.$(rev:.r)，它应该可以按预期工作。

Answer 2

Azure Pipeline Nuget 包版本控制方案，如何获取“1.0.$(Rev:r)”

这应该是文档中的一个问题。我在构建管道的选项中以内部版本号格式设置$(Major).$(Minor).$(rev:.r) 时重现了此问题：

然而，经过多次构建测试后，我突然注意到构建号与该格式不正确：

在 0 和 2 之间有 两个 点 .（在新标签页中打开上图）。显然这很奇怪。因此，我将内部版本号格式更改为：

$(Major).$(Minor)$(rev:.r)

或者

$(Major).$(Minor).$(rev:r)

现在，一切正常。

作为测试，我只是将Build number格式设置为$(rev:.r)，build number是.x。所以，我们可以确认$(rev:.r)的值默认包括.。

注意：由于其中Major和Minor是构建管道中定义的两个变量，所以我们需要在变量中手动定义它们。

希望这会有所帮助。

Answer 3

使用 byBuildNumber 进行打包/版本控制的工作 YAML 示例

注意counter 的第二个参数 - 它是一个种子值，在从其他构建系统（如 TeamCity）迁移构建时非常有用；它允许您在迁移时明确设置下一个构建版本。在 Azure DevOps 中迁移和初始构建后，每次更改 majorMinorVersion 时，种子值都可以设置回零或您可能喜欢的任何起始值（如 100）：

参考：counter expression

name: $(majorMinorVersion).$(semanticVersion) # $(rev:r) # NOTE: rev resets when the default retention period expires

pool: 
  vmImage: 'vs2017-win2016' 

# pipeline variables
variables:
  majorMinorVersion: 1.0
  # semanticVersion counter is automatically incremented by one in each execution of pipeline
  # second parameter is seed value to reset to every time the referenced majorMinorVersion is changed
  semanticVersion: $[counter(variables['majorMinorVersion'], 0)]
  projectName: 'MyProjectName'
  buildConfiguration: 'Release'

# Only run against master
trigger:
- master

# Build
- task: DotNetCoreCLI@2
  displayName: Build
  inputs:
    projects: '**/*.csproj'
    arguments: '--configuration $(BuildConfiguration)'

# Package
- task: DotNetCoreCLI@2
  displayName: 'NuGet pack'
  inputs:
    command: 'pack'
    configuration: $(BuildConfiguration)
    packagesToPack: '**/$(ProjectName)*.csproj'
    packDirectory: '$(build.artifactStagingDirectory)'
    versioningScheme: byBuildNumber # https://docs.microsoft.com/en-us/azure/devops/pipelines/tasks/build/dotnet-core-cli?view=azure-devops#yaml-snippet

# Publish
- task: DotNetCoreCLI@2
  displayName: 'Publish'
  inputs:
    command: 'push'
    nuGetFeedType: 'internal'
    packagesToPush: '$(build.artifactStagingDirectory)/$(ProjectName)*.nupkg'
    publishVstsFeed: 'MyPackageFeedName'

Answer 4

我有类似的问题，现在让我说清楚。

首先，Build Number的定义是什么？

通过Azure Pipeline YAML scheme的官方文档，是

name: string  # build numbering format
resources:
  containers: [ containerResource ]
  repositories: [ repositoryResource ]
variables: { string: string } | [ variable | templateReference ]
trigger: trigger
pr: pr
stages: [ stage | templateReference ]

看第一行：

name: string  # build numbering format

是的，就是这样！

所以你可以这样定义它

name: 1.0.$(Rev:r)

如果您更喜欢语义版本控制。那么

其次，任务NuGetCommand@2中versioningScheme: 'byBuildNumber'是什么意思？

真的很简单：只需使用name定义的格式！

最后但并非最不重要的一点

Package Versioning 和Pack NuGet packages 上的官方文档并没有明确说明内部版本号到底是什么以及如何定义它。这真的很误导人。作为一名 MS 员工，我很伤心，因为我不得不求助于外部资源来澄清这一切。

Answer 5

我有一个解决方法来添加后缀（即“-beta”），因为在使用经典编辑器并按内部版本号设置自动版本控制时，Nuget pack 命令出于某种原因忽略了它：

1. 设置一个新的环境变量，将值设置为预定义的$(Build.BuildNumber)变量：
   
   

2. 设置内部版本号：
   
   

3. 将 NuGet pack 命令设置为按环境变量自动命名并指定新添加的变量名称：
   
   

如果您对整个构建/发布管道设计和 YAML 感兴趣，请查看我的文章 here