Управление версиями пакетов Nuget и продвижение с CI на рабочие каналы Nuget

Технологии:

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

TFS - локальное обновление 2017 г. 1

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

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

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

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

введите описание изображения здесь

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

Вопрос:

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

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

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

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

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

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


person GetFuzzy    schedule 03.11.2017    source источник


Ответы (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 анализировать трехзначное управление версиями для упаковки NuGet

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

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

person PatrickLu-MSFT    schedule 06.11.2017
comment
Оказывается, мы почти можем делать то, что хотим, но это все еще огромная боль. Мы возвращаемся к использованию процесса пост-сборки в файле решения, чтобы запускать наши сборки для потока производственных пакетов. - person GetFuzzy; 16.11.2017
comment
@GetFuzzy Приятно слышать это, использование процесса пост-сборки в решении может быть немного сложным и громоздким, но эффективным. Получив готовое решение, вы можете поделиться им здесь. - person PatrickLu-MSFT; 16.11.2017
comment
Вы можете отключить автоматическое управление версиями и просто указать этот дополнительный параметр в команде PACK. Version=1.0.$(Build.BuildId) - person Piotr Kula; 06.11.2018
comment
Было бы неплохо, если бы задача dotnet pack имела выходную переменную для версии, теперь требуется много предварительной работы, чтобы установить переменную в номере сборки и использовать этот номер сборки. Автоматическое управление версиями пакетов неэффективно. Как насчет задачи интеграции источников индекса и публикации символов? также требуется версия ... - person rfcdejong; 19.03.2019