Сохранять номер версии на всех этапах сборки и в конфигурациях сборки

Question

Я использую TeamCity 6.5.4, и мне нужно иметь 3 конфигурации сборки для одного пакета развертывания.Я хотел бы сохранить номер версии во всех трех конфигурациях сборки и иметь возможность использовать этот номер для создания версии сборки, тега vcs, версии файла nuspec и т. Д.

Вот конфигурации и требуемые номера версий:

 Configuration     |  Version  
-------------------|---------
 CI/Nightly Build  |  1.1.*
 Minor Release     |  1.*.0
 Major Release     |  *.0.0

Кажется, что TeamCity использует отдельный инкрементатор сборки для каждой конфигурации.Это означает, что каждый раз, когда мы выпускаем основной или вспомогательный выпуск, мне придется вручную обновлять постоянные значения (1) во всех последующих конфигурациях.Я программист и я ленивый.Я хочу, чтобы одна кнопка сделала все для меня.

Я видел примеры сохранения номера сборки на этапах сборки конфигурации с зависимыми моментальными снимками, но она работает только в той же конфигурации.

Плагин Autoincrementer увеличивает число каждый каждый раз, когда вы ссылаетесь на идентификатор.Это хорошо для меняющихся чисел (*), но не так хорошо для ссылки на постоянные значения (1).

Есть ли способ для TeamCity, изначально или с помощью плагина, позволить мне читать и писатьэта версия в файл или переменную, которая может быть сохранена в конфигурациях сборки?

Answer 1

Вы можете ссылаться на номер сборки зависимой (артефакт / снимок) конфигурации , используя dep.btx.build.number, где btx - идентификатор bt последнего.Получив номер сборки, передайте номер сборки в свой скрипт, работающий в конфигурации, проанализируйте номер сборки в сценарии и отправьте служебные сообщения из сценария в Teamcity, чтобы установить номер сборки так, какхочу.Выполните этот анализ и настройте номер как первый шаг в вашем скрипте / первый шаг в шагах сборки.

Answer 2

Спасибо за предложения. Я решил написать набор пользовательских целей для использования со своим сценарием MSBuild, который поддерживает метаданные сборки в удаленном XML-файле "манифеста". Когда создается новый проект TeamCity, мой скрипт сборки вызывает цель Init, которая создает новый файл манифеста из незаполненного шаблона.

<Copy SourceFiles="@(ManifestTemplate)" DestinationFiles="@(ManifestTemplate->'$(ManifestFile)')" Condition="!Exists('$(ManifestFile)')" />

Я использую пакет MSBuild Extentions для чтения атрибутов, таких как информация о версии, из файла манифеста.

<MSBuild.ExtensionPack.Xml.XmlFile TaskAction="ReadElementText" File="$(ManifestFile)" XPath="/Package/Version/Major">
  <Output PropertyName="PackageVersionMajor" TaskParameter="Value"/>
</MSBuild.ExtensionPack.Xml.XmlFile>

У меня есть конфигурации сборки TeamCity, разделенные на CI, Test, Minor Release и Major Release с различными событиями, запускающими каждую. Из соответствующей цели в сценарии сборки моего проекта я добавляю новую цель в атрибут DependsOnTargets, чтобы вызвать настраиваемую цель, чтобы обновить соответствующий номер версии и сохранить его в файле манифеста.

<Target Name="Test" DependsOnTargets="IntializeBuildProject;Build-UpdateVersion-Build">
<MSBuild Projects="$(SolutionFile)" Targets="Rebuild" Properties="Configuration=$(Configuration)" />
<TeamCitySetBuildNumber BuildNumber="$(PackageVersion)" />

Код в пользовательской цели для обработки обновления версии:

<MSBuild.ExtensionPack.Science.Maths TaskAction="Add" Numbers="$(PackageVersionBuild);1">
  <Output PropertyName="PackageVersionBuild" TaskParameter="Result"/>
</MSBuild.ExtensionPack.Science.Maths>
<MSBuild.ExtensionPack.Xml.XmlFile TaskAction="UpdateElement" File="$(ManifestFile)" XPath="/Package/Version/Build" InnerText="$(PackageVersionBuild)"/>

Этот файл обрабатывает сохранение версии и других метаданных, игнорируя таким образом номер сборки TeamCity. Поскольку файл метаданных XML является централизованным, я могу использовать эти значения для заполнения метаданных Nuspec, AssemblyInfo и WiX Installer, а также передавать версию и другую соответствующую информацию обратно в TeamCity через служебные сообщения.

Я добавил простой веб-интерфейс MVC, чтобы позволить моей команде удаленно редактировать содержимое файла при изменении сведений о пакете. Теперь у нас есть единственное место для обновления таких вещей, как информация об авторских правах и любые другие метаданные для данного проекта сборки. Я также могу предоставить не-dev людям доступ к сайту MVC для обновления информации о брендинге, не предоставляя им доступ к моим конфигурациям сборки TeamCity.

За исключением служебных сообщений, используемых для передачи версии в TeamCity, здесь очень мало того, что связано с TeamCity. Мне нравится, когда функциональность в пользовательских целях и сценариях сборки удаляются из TeamCity, когда мы можем перейти к другому решению для управления сборкой. По этой причине я не планирую тратить время на создание плагина TeamCity, но скоро может появиться серия блогов.

Я буду рад предоставить больше кода и дальнейших объяснений всем, кто заинтересован.

Answer 3

Да, вы можете создать плагин, чтобы сделать это легко.Вы можете взять мой плагин с автоинкрементным номером сборки (для разных конфигураций) и изменить его под свои нужды.Номер сборки будет сохранен в текстовом файле, который настраивается на экране администратора в TeamCity.

http://github.com/ornatwork/tc_plugins/tree/master/unique

Вы можете задать мне вопрос, как изменить его, если вам нужно.