2016-12-13 10 views
0

Я использую GitVersion (версия 3.5.3, если это имеет значение), и получаю неожиданные результаты; в частности, выпущенная версия имеет неожиданную часть подсчета фиксации. Глядя на журнал, я вижу, что подсчет фиксации вычисляется правильно, но базовая версия, используемая GitVersion, неверна (или, по крайней мере, не так, как я думал, это будет).Как определить, почему GitVersion выбрала конкретную базовую версию?

Однако файл журнала для GitVersion менее полезен, он просто перечисляет серию тегов, затем длинный список баз слияния, и в конце он просто говорит, какую базовую версию он решил использовать.

Может ли GitVersion сообщить мне почему-то, почему он выбрал конкретную базовую версию?

+0

Возможно ли, чтобы вы показали результат, который видите? Или это на публичном репо? –

+0

@GaryEwanPark Это частное репо. Сейчас я просматриваю источник GitVersion, чтобы понять его решение. – user145400

ответ

0

Я не уверен, вы уже проверили или нет; но объясняется, как они вычисляют базовую версию, а также новые версии в своих documentation

ОБНОВЛЕНИЕ: добавлена ​​основная информация из документации.

Архитектура

GitVersion состоит из трех этапов окрености для расчета версии в v3.0.

  • Если текущая фиксация отмечена, используется тег и добавляются метаданные (Исключая количество фиксации). Остальные два шага не будут выполняться
  • Набор стратегий оценивается для определения базовой версии и некоторых метаданных об этой версии. Эти стратегии включают в себя HighestReachableTag, NextVersionInConfig, MergedBranchWithVersion, VersionInBranchName и т.д.
  • Самая высокая базовая версия выбрана, с помощью этой базовой версии новая версия рассчитывается.

Визуально это выглядит примерно так: enter image description here

Базовая версия Стратегии

  • HighestTagBaseVersionStrategy - находит самый высокий достижимый тег из текущая ветвь
  • VersionInBranchBaseVersionStrategy - Выдает информацию о версии с названия филиала. например, выпуск/3.0.0 найдет 3.0.0
  • ConfigNextVersionBaseVersionStrategy - Возвращает версию из GitVersion.yaml файл
  • MergeMessageBaseVersionStrategy - Находит номера версий от слияния сообщений. например. Merge 'релиз/3.0.0' в 'мастера' возвратит 3.0.0
  • FallbackBaseVersionStrategy - Всегда возвращает 0.1.0 для новых хранилищ

Каждая стратегия должна возвращать экземпляр BaseVersion, который имеет следующие свойства

  • Источник - Описание источника. например, `Merge сообщение«Merge „релиз/3.0.0“ в „мастер“»
  • ShouldIncrement - Некоторые стратегии должны иметь версию увеличивается, а другие нет. например ConfigNextVersionBaseVersionStrategy возвращает ложь, HighestTagBaseVersionStrategy возвращает истину
  • SemanticVersion - SemVer стратегии базовой версии
  • BaseVersionSource - Ша источника. Конец будет засчитан от этой Ша. Может быть пустым (например, ConfigNextVersionBaseVersionStrategy возвращает нулевое значение)
  • BranchNameOverride - Когда useBranchName или {BranchName} используется в конфигурация тега, это позволяет название филиала быть изменен базовой версии с. VersionInBranchBaseVersionStrategy использует это, чтобы удалить что-либо перед первым - или /. Таким образом, foo заканчивается оценкой как foo. Если у вас есть сомнения, просто используйте нуль
+0

Хотя ваш ответ на 100% правильный, он также может стать 100% бесполезным , если эта ссылка перемещена, изменена, объединена в другую или основной сайт просто исчезает ... **: - (** Поэтому, пожалуйста [ отредактируйте] (http://stackoverflow.com/posts/41962010/edit) и скопируйте соответствующие шаги из ссылки в свой ответ, тем самым гарантируя ваш ответ за 100% срока службы этого сайта! ** ; -) ** Вы всегда можете оставить ссылку в нижней части вашего ответа в качестве источника для вашего материала ... –

+0

@DonaldDuck спасибо за информацию, вы совершенно правы :) – nzrytmn