Azure Pipeline Nuget 包版本控制方案，如何获取“1.0.$(Rev:r)”
Azure Pipeline Nuget Package Versioning Scheme, How to Get "1.0.$(Rev:r)"
我正在设置一个 Azure Pipelines 构建，它需要将 C# .NET class 库打包到 NuGet 包中。
在 this documentation 中，它列出了几种不同的自动生成 SemVer 字符串的方法。特别是，我想实现这个：
$(Major).$(Minor).$(rev:.r), where Major and Minor are two variables
defined in the build pipeline. This format will automatically
increment the build number and the package version with a new patch
number. It will keep the major and minor versions constant, until you
change them manually in the build pipeline.
但这就是他们所说的一切，没有提供任何例子。要了解更多信息，link 会将您带到 this documentation，其中显示：
For byBuildNumber, the version will be set to the build number, ensure
that your build number is a proper SemVer e.g. 1.0.$(Rev:r). If you
select byBuildNumber, the task will extract a dotted version, 1.2.3.4
and use only that, dropping any label. To use the build number as is,
you should use byEnvVar as described above, and set the environment
variable to BUILD_BUILDNUMBER.
同样，没有提供示例。看起来我想使用 versioningScheme: byBuildNumber，但我不太确定如何设置内部版本号，我认为它是从 BUILD_BUILDNUMBER 环境变量中提取的，但我找不到方法设置环境变量，只有脚本变量。此外，我是否应该将其设置为 1.0.$(Rev:r) 或 $(Major).$(Minor).$(rev:.r)？恐怕只能按字面解释了。
用谷歌搜索文字字符串 "versioningScheme: byBuildNumber" returns 一个单一的结果...有没有人使用这个版本控制方案 azure-pipelines.yml？
byBuildNumber 使用您在 YAML 中通过 name 字段定义的内部版本号。
例如：name: $(Build.DefinitionName)-$(date:yyyyMMdd)$(rev:.r)
因此，如果您将构建格式设置为 name: 1.0.$(rev:.r)，它应该会按预期工作。
Azure Pipeline Nuget Package Versioning Scheme, How to Get “1.0.$(Rev:r)”
这应该是文档中的一个问题。当我在构建管道选项中的构建编号格式中设置 $(Major).$(Minor).$(rev:.r) 时，我重现了这个问题：
但是，经过多次构建测试后，我突然发现构建号与该格式不正确：
在 0 和 2 之间有 两个 点 .（在新选项卡中打开上图）。显然这很奇怪。因此，我将内部版本号格式更改为：
$(Major).$(Minor)$(rev:.r)
或
$(Major).$(Minor).$(rev:r)
现在，一切正常。
作为测试，我只是将内部版本号格式设置为$(rev:.r)，内部版本号为.x。因此，我们可以确认 $(rev:.r) 的值默认包括 .。
注意：由于Major和Minor是构建管道中定义的两个变量，所以我们需要在变量中手动定义它们。
希望对您有所帮助。
Packaging/Versioning 使用 byBuildNumber
的工作 YAML 示例
注意 counter 的第二个参数 - 它是一个种子值，在从其他构建系统（如 TeamCity）迁移构建时非常有用；它允许您在迁移时明确设置下一个构建版本。在 Azure DevOps 中迁移和初始构建后，每次 majorMinorVersion 更改时，种子值都可以设置回零或您可能更喜欢的任何起始值（如 100）：
reference: 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'
我遇到了类似的问题，现在让我说清楚。
首先，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 and Pack NuGet packages 上的官方文档没有明确说明什么是内部版本号以及如何定义它。这真的很误导人。作为一名 MS 员工，我感到非常难过，因为我不得不求助于外部资源来澄清这一切。
我有一个变通方法可以添加后缀（即“-beta”），因为在使用经典编辑器并设置自动时，出于某种原因它被 Nuget pack 命令忽略按内部版本号进行版本控制：
设置一个新的环境变量，设置值为预定义的$(Build.BuildNumber)变量：
设置内部版本号：
设置NuGet pack命令为环境变量自动命名并指定新添加的变量名：
如果您对整个 build/release 管道设计和 YAML 感兴趣，请查看我的文章 here
问题
我的问题：
- 在尝试
时，我的第一个包从 2.0 开始（我没有做进一步的测试来调查）
- 尝试
时，我找不到匹配的“选项”选项卡。
因此我使用了。
修复
设置变量：
variables:
major: '1'
minor: '0'
revision: $[counter(variables['minor'], 1)] # This will get reset every time minor gets bumped.
nugetVersion: '$(major).$(minor).$(revision)'
然后打包时使用nugetVersion :
- task: NuGetCommand@2
inputs:
command: 'pack'
packagesToPack: '**/*.csproj'
packDestination: '$(Build.ArtifactStagingDirectory)'
versionEnvVar: 'nugetVersion'
versioningScheme: 'byEnvVar'
我认为很多用户的问题是没有选项菜单。我对 SHarpC 的 post 投了赞成票，因为这对我有用。
我正在设置一个 Azure Pipelines 构建，它需要将 C# .NET class 库打包到 NuGet 包中。
在 this documentation 中，它列出了几种不同的自动生成 SemVer 字符串的方法。特别是，我想实现这个：
$(Major).$(Minor).$(rev:.r), whereMajorandMinorare two variables defined in the build pipeline. This format will automatically increment the build number and the package version with a new patch number. It will keep the major and minor versions constant, until you change them manually in the build pipeline.
但这就是他们所说的一切，没有提供任何例子。要了解更多信息，link 会将您带到 this documentation，其中显示：
For
byBuildNumber, the version will be set to the build number, ensure that your build number is a proper SemVer e.g.1.0.$(Rev:r). If you select byBuildNumber, the task will extract a dotted version,1.2.3.4and use only that, dropping any label. To use the build number as is, you should use byEnvVar as described above, and set the environment variable toBUILD_BUILDNUMBER.
同样，没有提供示例。看起来我想使用 versioningScheme: byBuildNumber，但我不太确定如何设置内部版本号，我认为它是从 BUILD_BUILDNUMBER 环境变量中提取的，但我找不到方法设置环境变量，只有脚本变量。此外，我是否应该将其设置为 1.0.$(Rev:r) 或 $(Major).$(Minor).$(rev:.r)？恐怕只能按字面解释了。
用谷歌搜索文字字符串 "versioningScheme: byBuildNumber" returns 一个单一的结果...有没有人使用这个版本控制方案 azure-pipelines.yml？
byBuildNumber 使用您在 YAML 中通过 name 字段定义的内部版本号。
例如：name: $(Build.DefinitionName)-$(date:yyyyMMdd)$(rev:.r)
因此，如果您将构建格式设置为 name: 1.0.$(rev:.r)，它应该会按预期工作。
Azure Pipeline Nuget Package Versioning Scheme, How to Get “1.0.$(Rev:r)”
这应该是文档中的一个问题。当我在构建管道选项中的构建编号格式中设置 $(Major).$(Minor).$(rev:.r) 时，我重现了这个问题：
但是，经过多次构建测试后，我突然发现构建号与该格式不正确：
在 0 和 2 之间有 两个 点 .（在新选项卡中打开上图）。显然这很奇怪。因此，我将内部版本号格式更改为：
$(Major).$(Minor)$(rev:.r)
或
$(Major).$(Minor).$(rev:r)
现在，一切正常。
作为测试，我只是将内部版本号格式设置为$(rev:.r)，内部版本号为.x。因此，我们可以确认 $(rev:.r) 的值默认包括 .。
注意：由于Major和Minor是构建管道中定义的两个变量，所以我们需要在变量中手动定义它们。
希望对您有所帮助。
Packaging/Versioning 使用 byBuildNumber
注意 counter 的第二个参数 - 它是一个种子值，在从其他构建系统（如 TeamCity）迁移构建时非常有用；它允许您在迁移时明确设置下一个构建版本。在 Azure DevOps 中迁移和初始构建后，每次 majorMinorVersion 更改时，种子值都可以设置回零或您可能更喜欢的任何起始值（如 100）：
reference: 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'
我遇到了类似的问题，现在让我说清楚。
首先，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 and Pack NuGet packages 上的官方文档没有明确说明什么是内部版本号以及如何定义它。这真的很误导人。作为一名 MS 员工，我感到非常难过，因为我不得不求助于外部资源来澄清这一切。
我有一个变通方法可以添加后缀（即“-beta”），因为在使用经典编辑器并设置自动时，出于某种原因它被 Nuget pack 命令忽略按内部版本号进行版本控制：
设置一个新的环境变量，设置值为预定义的
$(Build.BuildNumber)变量：
设置内部版本号：
设置NuGet pack命令为环境变量自动命名并指定新添加的变量名：
如果您对整个 build/release 管道设计和 YAML 感兴趣，请查看我的文章 here
问题
我的问题：
- 在尝试
- 尝试
因此我使用了
修复
设置变量：
variables:
major: '1'
minor: '0'
revision: $[counter(variables['minor'], 1)] # This will get reset every time minor gets bumped.
nugetVersion: '$(major).$(minor).$(revision)'
然后打包时使用nugetVersion
- task: NuGetCommand@2
inputs:
command: 'pack'
packagesToPack: '**/*.csproj'
packDestination: '$(Build.ArtifactStagingDirectory)'
versionEnvVar: 'nugetVersion'
versioningScheme: 'byEnvVar'
我认为很多用户的问题是没有选项菜单。我对 SHarpC 的 post 投了赞成票，因为这对我有用。