Как начать сборку vNext TFS 2015 с определенного номера
Я использую систему сборки vNext TFS 2015.
В настоящее время у меня есть версии моих сборок в традиционном формате. MAJOR.MINOR-rev.RevisionNumber. Итак, если у меня есть сборка для Major 1, Minor 12, версия сборки будет выглядеть как 1.12-rev.1 при запуске. Я хотел бы знать, возможно ли, чтобы версия сборки начиналась с номера, отличного от единицы, скажем, 55. Так, чтобы версия сборки выглядела как 1.12-rev.55, а затем увеличивалась на единицу, как обычно, после этого.
7 ответов
К сожалению, это невозможно.
Каждое определение сборки имеет поле формата номера сборки, где вы можете использовать некоторые макросы, чтобы определять, как должен выглядеть полученный номер сборки. В этом формате мы используем $(Rev:.rr) Его начало одним.
Что такое $(Rev:.rr)?
Чтобы каждая завершенная сборка имела уникальное имя. Когда сборка завершена, если больше ничего в номере сборки не изменилось, целочисленное значение Rev увеличивается на единицу.
Источник: MSDN
Более того, если вы хотите генерировать пользовательский номер сборки без приращения. Вот блог с подробными процедурами: Генерация пользовательских номеров сборки в TFS Build vNext
На самом деле, это можно сделать в сборке vNext без взлома базы данных.
Есть 2 шага.
Во-первых, вам нужно реализовать шаг сборки powershell (как первый шаг сборки) с помощью следующего встроенного скрипта:
#Set the BuildNumberOffset. (Change this to the difference between the TFS build number,
#and the number that your build needs.)
$BuildNumberOffset = 543
#Don't change
$BuildNumberParts = $($env:BUILD_BUILDNUMBER) -split '\.'
$TFSRevision = [int]$BuildNumberParts[$BuildNumberParts.Length-1]
$BuildNumberParts[$BuildNumberParts.Length-1] = ($TFSRevision + $BuildNumberOffset).ToString()
$BuildNumber = [string]::Join(".", $BuildNumberParts)
Write-Host "##vso[build.updatebuildnumber]$BuildNumber"
Во-вторых, в поле "Метка формата" на вкладке репозитория установите формат метки "$(Build.BuildNumber)" вместо "$(Build.DefinitionName)$(rev:.r)". Это важно, чтобы ваш ярлык совпадал с вашим обновленным номером сборки.
Есть способ сделать это. Это не красиво, но это работает.
Предполагая, что у вас есть формат номера сборки что-то вроде $(Major).$(Minor)-rev$(rev:.r)
Для этого поставьте в очередь сборку, которая получит номер 1.12-rev.1. Затем перейдите в базу данных TFS и в таблицу под названием tbl_Build, Найдите последнюю сборку и измените значение в BuildNumberRevision столбец до 54.
Следующая начавшаяся сборка теперь будет 1.12-rev.55.
Это также было очень болезненно для нас, миграция с существующей системы CI с собственной нумерацией сборок, нам нужно было, чтобы номера сборок увеличивались с определенного значения. В организации не разрешалось взламывать базы данных, зачеты казались помехой.
В конце концов, мы использовали скрипт AutoIt для запуска и остановки сборки и удаления результата сборки с помощью веб-интерфейса и оставили его работающим. Не приятно, но это сделало работу.
Требуется настройка разрешения экрана и т. д., возможно, также тайминга. Используйте AutoIt Window Info, чтобы найти расположение кнопок, убедитесь, что браузер работает в полноэкранном режиме (не в окне). Запустите его на несколько циклов, чтобы убедиться, что он надежный, прежде чем увеличивать цикл.
#include <AutoItConstants.au3>
;Increment TFS build count (Chrome browser buttons locations). Start from build result page.
For $i = 1 To 15 Step 1
ConsoleWrite ( "Loop " & $i & " of 5" & @CRLF )
Sleep(200)
MouseClick($MOUSE_CLICK_PRIMARY, 1800, 200, 2)
Sleep(500)
MouseClick($MOUSE_CLICK_PRIMARY, 1150, 881, 2)
Sleep(2000)
MouseClick($MOUSE_CLICK_PRIMARY, 1800, 200, 2)
Sleep(500)
MouseClick($MOUSE_CLICK_PRIMARY, 1055, 165, 2)
Sleep(10000)
Next
TFS/Devops — это действительно незрелая система CI, и это не патч для того, что мы использовали. К сожалению, корпоративная политика говорит, что мы переходим на TFS, так как никто никогда не был уволен за покупку продуктов Microsoft (но многие люди должны были быть уволены за их покупку / принуждение их туда, где им не место).
Не могли бы мы просто установить это вручную в формате для одной сборки, то есть:
$(Major).$(Minor)-rev$(rev:.54)
и затем вернитесь обратно к:
$(Major).$(Minor)-rev$(rev:.r)
Не пробовал, но если это сработает, это сохранит хакинг в базе данных.
Вы можете сделать это легко, но только если вы используете Git-репозиторий в сочетании с инструментом под названием GitVersion
Это замечательный инструмент, который я всегда использую в своих репозиториях git. Для вашего варианта использования: если у вас есть версия 1.2.3, и вы хотите перейти к версии 1.2.55, вы просто добавляете тег git 'v1.2.55', и он начнет версионирование оттуда. GitVersion намного сложнее и делает намного больше, но это одна из особенностей. Вам не нужно связываться со специальными сценариями PowerShell или чем-то еще, вместо этого он читает историю вашего git-репо, а теги git переопределяют рассчитанное управление версиями. Уже есть расширение TFS/VSTS/Azure Devops под названием GitVersion, которое прекрасно работает от того же разработчика.
Ответ @Steve Sims по-прежнему работает с TFS 2017 vNext. Большое спасибо!
Мне оставалось только сделать первый шаг, "чтобы добавить скрипт как встроенный скрипт powershell в мою сборку". Благодаря @PainElemental
С этим "Форматом номера сборки" во вкладке "Параметры" он работает:
$(BuildDefinitionName)_1.2.0$(rev:.r)
Я не помечал свои источники при сборке, поэтому я не проверял:
Во-вторых, в поле "Метка формата" на вкладке репозитория установите формат метки "$(Build.BuildNumber)" вместо "$(Build.DefinitionName)$(rev:.r)". Это важно, чтобы ваш ярлык совпадал с вашим обновленным номером сборки.
Я думаю, вы можете редактировать формат метки в "Расширенных" опциях GetSources. (обычно скрытый).