Блог

Я использую 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, либо изначально, либо через плагин, позволяющий мне читать и записывать эту версию в файл или переменную, которая может сохраняться в конфигурациях сборки?

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

Спасибо за предложения. Я решил написать набор пользовательских целевых объектов для использования с моим скриптом MSBuild, который поддерживает метаданные сборки в удаленном файле xml «manifest». При создании нового проекта TeamCity мой сценарий сборки вызывает целевой объект инициализации, который создает новый файл манифеста из незаселенного шаблона.

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

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

 <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, а также передавать версию и другую соответствующую информацию обратно в TeamCity через служебные сообщения.

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

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

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

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

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

Вы можете связаться со мной, чтобы узнать, как это изменить, если вам нужно.