Схема создания версий пакета Nuget для конвейера Azure. Как получить «1.0. $ (Rev: r)»

Question

Я настраиваю сборку Azure Pipelines, которая должна упаковать библиотеку классов C # .NET в пакет NuGet.

В этой документации в ней перечислены несколько различных способовавтоматически генерировать строки SemVer.В частности, я хочу реализовать это:

$(Major).$(Minor).$(rev:.r), где Major и Minor - две переменные, определенные в конвейере сборки.Этот формат автоматически увеличивает номер сборки и версию пакета с новым номером патча.Он будет поддерживать основную и вспомогательную версии постоянными, пока вы не измените их вручную в конвейере сборки.

Но это все, что они говорят об этом, никакого примера не приводится.Ссылка для получения дополнительной информации приведет вас к этой документации , где говорится следующее:

Для 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)?Я боюсь, что это будет просто интерпретировать это буквально.

Поиск в Google для буквенной строки "versioningScheme: byBuildNumber" возвращает один результат ... У кого-нибудь есть работающий azure-pipelines.yml с этой схемой управления версиями?

Answer 1

У меня была похожая проблема, и теперь позвольте мне прояснить ее.

Во-первых, каково определение Номер сборки ?

Официальным документом Схема YAML для конвейера Azure , это

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' в задаче NuGetCommand @ 2?

Это действительно просто: просто используйте формат, определенный как name!

Последний, ноне менее важно:

Официальный документ Управление версиями пакетов и Пакеты NuGet для пакетов не дают понять, что на самом деле представляет собой номер сборки и как его определить.Это действительно вводит в заблуждение.И мне, как сотруднику MS, так грустно, что я прибегаю к внешним ресурсам, чтобы прояснить все это.

Answer 2

Схема создания версий пакета Nuget конвейера Azure. Как получить «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 - это две переменные, определенные в конвейере сборки, поэтому нам нужно определитьих в переменных вручную.

Надеюсь, это поможет.

Answer 3

Рабочий пример YAML для Упаковки / Версионирования с использованием byBuildNumber

ПРИМЕЧАНИЕ Второй параметр counter - это начальное значение, действительно полезное при переносе сборок из другой сборкитакие системы, как TeamCity;Это позволяет вам явно установить следующую версию сборки после миграции.После миграции и начальной сборки в DevOps Azure начальное значение может быть установлено на ноль или на любое другое начальное значение (например, 100), которое вы предпочитаете каждый раз, когда изменяется majorMinorVersion:

ссылка: выражение счетчика

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

byBuildNumber использует номер сборки, который вы определили в YAML с полем name.

Пример: name: $(Build.DefinitionName)-$(date:yyyyMMdd)$(rev:.r)

Так что если вы установите формат сборки на name: 1.0.$(rev:.r), он должен работать, как вы ожидаете.