Вопрос:

GitVersion - выборочное управление версиями нескольких сборок одного проекта

semantic-versioning gitversion

536 просмотра

2 ответа

1 Репутация автора

Я нахожусь на проекте .net c #, составленном решением с несколькими проектами библиотеки классов.

Управление исходным кодом управляется git с использованием gitflow в качестве модели ветвления. Мы решили, что хотим реализовать семантическое управление версиями ( http://semver.org/ ) проекта, чтобы следовать стандартному способу передачи наших релизов. Для этого мы используем GitVersionTask (через NuGet), который довольно хорошо работает с gitflow.

Каждый раз, когда мы помечаем выпуск и выполняем сборку из главной ветви, обновляются версии всех сборок и выходит новый выпуск. Только одна из сборок имеет открытый API, все остальные предназначены для внутреннего использования. Я хотел бы знать, если это правильный способ управления версией нескольких сборок одного и того же проекта, я имею в виду, не неправильно ли менять версию каждой сборки, когда была изменена только пара (или даже только одна)? Чтобы усложнить задачу, существует большая вероятность того, что некоторые «внутренние» сборки будут использоваться другими проектами, поэтому я считаю, что не очень разумно увеличивать основную версию сборки, которая не претерпела изменений, только потому, что другая сборка тот же проект продвигает серьезные изменения. Должен ли каждый сборочный проект управляться в собственном репозитории?

Заранее спасибо.

Автор: devrenew Источник Размещён: 22.08.2016 08:33

Ответы (2)


0 плюса

8753 Репутация автора

В GitVersion, безусловно, нет ничего, что помогло бы иметь отдельные проекты в одном репозитории. Руководство, которое мы предлагаем здесь, заключается в том, что вы должны использовать разные репозитории для разных частей вашего приложения. Таким образом, они могут быть версионированы / обновлены по своему усмотрению.

Автор: Gary Ewan Park Размещён: 23.08.2016 07:26

1 плюс

21 Репутация автора

Я знаю, что это старый вопрос, но все же:

Я хочу поделиться решением, которое, кажется, работает:

  1. GitVersion использует $ (Build.SourcesDirectory), чтобы увидеть, где находятся источники - src
  2. Мы можем изменить это, используя команды регистрации *

  3. Обходной путь должен установить Build.SourcesDirectory перед задачей GitVersion

  4. Затем gitVersion использует GitVersion.yml из папки проекта (Build.SourceDirectory) и вуаля - работает

После этого вы можете откатить изменение или нет - в зависимости от ваших потребностей. Для меня, кажется, неплохо бы охватить единственный пакет nuget из коллекции пакетов nuget в нашем monorepo nugetPackages.

см. проблему GitVersion и комментарий

* Пример команды Powershell: стандартная задача PowerShell; установить встроенный скрипт; Write-Host "## vso [task.setvariable variable = Build_SourcesDirectory;] $ (Build.SourcesDirectory) \ $ (NugetProjectName)"

Автор: Georgi Размещён: 05.10.2018 11:48
Вопросы из категории :
32x32