Создание версий Nuget и продвижение из CI в каналы производства Nuget

Question

технологии:

Proget - сервер управления пакетами Nuget

TFS - В помещении 2017 Обновление 1

Проблема. При повторном выпуске сборки из выпуска TFS для повторной упаковки пакета CI Nuget, который уже был добавлен в мой канал разработки Proget, не существует способа получить автоматическое управление версиями Semantic. Диалоговое окно справки, которое появляется в отношении установки версии в настройке упаковщика Nuget, выглядит следующим образом.

Использовать дату и время Если вы выберете "Использовать дату и время", будет сгенерирована версия, совместимая с SemVer, в формате XYZ-ci-datetime, где вы выбираете X, Y и Z.

Использовать переменную среды Если вы выбираете "Использовать переменную среды", вы должны выбрать переменную среды и убедиться, что она содержит номер версии, которую вы хотите использовать.

Использовать номер сборки Если вы выберете "Использовать номер сборки", будет использоваться номер сборки для версии вашего пакета. Примечание. В разделе "Общие" установите для формата сборки значение "$(BuildDefinitionName)_$(Год: гггг).$(Месяц).$(День OfMonth)$(Rev:.r)

Я хотел бы иметь возможность переиздать пакет Nuget, который перешел от моей сборки CI в TFS к моему каналу разработки Proget, в мой рабочий канал Proget. У Microsoft есть отличная статья о версиях пакетов NuGet в мире непрерывной доставки. В этой статье они скрываются от того, что делают что-то похожее, но не дают никакого реального направления того, как это было достигнуто.

Вопрос:

Как бы вы сконфигурировали упаковщик Nuget, чтобы при создании пакета вы вводили переменную сборки? Или есть способ, которым вы могли бы установить основную версию и просто каждый раз вносить незначительный прирост? Как другие продвигают продвижение пакетов от разработки до производства?

Попробовал следующее:

Попробовал $(Version) как переменную build & release, но, похоже, он не работает. Посылка помечается датой. Кроме того, это только кажется действительно функциональным в части сборки TFS, где модальное окно содержит место для изменения этого значения.

Пробовал использовать метод даты и времени, и он вставляет CI в номер сборки. Это почти то, что мы хотим, за исключением определения CI. Поскольку он автоматически вставляет CI, это не подходит для производства.

Выключил его, и он извлекает версию из Nuspec, но тогда это предполагает, что в вашей сборке CI вы всегда увеличиваете номер версии на единицу больше, чем текущая, после того, как вы выдвинули свою последнюю версию выпуска. Это потому, что nuspec находится в файлах сборки, которые вы повторно выпускаете через цепочку выпуска TFS. Смущает, мягко говоря.

Используйте номер сборки, установленный в $ (BuildDefinitionName) $ (Year: yyyy).$(Month).$(DayOfMonth)$(Rev:.r). Здесь мне нужно $(Major).$(Minor).$(Patch). Попытка $(Version) $ с версией 1.0.0 дает вам файл с именем, у которого в качестве вывода будет 2017.11.3.1, по-видимому, игнорируя переменную $(Version).

Answer 1

Не уверен, что я полностью понял вашу точку зрения, похоже, вы хотели бы создать семантически версионный nupkg после процесса ci в TFS.

Обычно nupkg должен быть таким, как показано в MSVersioningSample: 1.0.8-ci-20171106-156033.nupkg

Однако вы бы хотели переименовать nupgk и повторно опубликовать его на сервере nuget, так как версия выпуска просто MSVersioningSample: 1.0.8.nupkg То же, что $(Major).$(Minor).$(Patch).

Вам нужно отредактировать NuGetPackager.ps1 в агенте сборки измените $VersionRegex значение, подробности, на которые вы могли бы взглянуть в ответе на этот вопрос: Как я могу получить TFS 2015 для анализа 3-значного управления версиями для упаковки NuGet

Также попробуйте какое-нибудь стороннее расширение для работы с семантическими версиями в сборке TFS, задачей выпуска, пакетом nuget, примером для справки: задачи сборки и выпуска семантической версии

Помимо примечания: Semantic Versioning 2.0.0 поддерживается только с NuGet 4.3.0+ и Visual Studio 2017 версии 15.3+.