C#.NETクラスライブラリをNuGetパッケージにパッケージ化する必要があるAzure Pipelinesビルドを設定しています。
このドキュメント には、SemVer文字列を自動的に生成するいくつかの異なる方法がリストされています。特に、これを実装したいと思います。
$(Major).$(Minor).$(rev:.r)
。ここで、Major
とMinor
は、ビルドパイプラインで定義された2つの変数です。この形式では、ビルド番号とパッケージバージョンが新しいパッチ番号で自動的に増分されます。ビルドパイプラインで手動で変更するまで、メジャーバージョンとマイナーバージョンを一定に保ちます。
しかし、それについて彼らが言うことはこれだけであり、例は提供されていません。詳細については、リンクをクリックすると このドキュメント に移動します。
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
_は誰かいますか?
byBuildNumber
は、name
フィールドでYAMLに定義したビルド番号を使用します。
例:name: $(Build.DefinitionName)-$(date:yyyyMMdd)$(rev:.r)
したがって、ビルド形式をname: 1.0.$(rev:.r)
に設定すると、期待どおりに機能するはずです。
byBuildNumber
を使用したパッケージング/バージョニングの実用的なYAMLの例
counter
の2番目のパラメーターに注意してください-これはシード値であり、TeamCityなどの他のビルドシステムからビルドを移行するときに本当に役立ちます。移行時に次のビルドバージョンを明示的に設定できます。 Azure DevOpsでの移行と初期ビルドの後、majorMinorVersion
が変更されるたびにシード値をゼロまたは任意の開始値(100など)に戻すことができます。
参照: カウンター式
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'
Azure Pipeline Nugetパッケージのバージョン管理スキーム、「1.0。$(Rev:r)」の入手方法
これはドキュメントの問題になるはずです。ビルドパイプラインのオプションのビルド番号形式で$(Major).$(Minor).$(rev:.r)
を設定すると、この問題が再現しました。
ただし、多くのビルドテストの後にビルド番号がその形式では正しくないことに突然気づきました。
2ポイント_.
_が0と2の間にあります(上の画像を新しいタブで開きます)。明らかにこれは非常に奇妙です。そこで、ビルド番号の形式を次のように変更しました。
_$(Major).$(Minor)$(rev:.r)
_
または
_$(Major).$(Minor).$(rev:r)
_
現在、すべてが正常に機能しています。
テストとして、ビルド番号の形式を$(rev:.r)
に設定しました。ビルド番号は。xです。したがって、デフォルトで_.
_を含む$(rev:.r)
の値を確認できました。
注:Major
とMinor
はビルドパイプラインで定義された2つの変数なので、変数に手動で定義する必要があります。
お役に立てれば。
私は同様の問題を抱えていましたが、それをはっきりさせておきます。
Azure Pipeline YAMLスキーム の公式ドキュメントでは、
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)
セマンティックバージョニングを希望する場合。その後
versioningScheme: 'byBuildNumber'
の意味は何ですか?これは本当に簡単です。name
で定義された形式を使用するだけです。
Package Versioning および Pack NuGet packages に関する公式ドキュメントでは、ビルド番号が実際に何であり、どのように定義するかが明確にされていません。それは本当に誤解を招くものです。また、MSの従業員としては、外部のリソースに頼ってすべてを明確にしたのでとても悲しいです。