Не используйте файлы в исходном репо для отслеживания текущей / следующей версии. Я не думаю, что вы можете легко разорвать цикл, если вы это сделаете.
Возможно, вам удастся сбежать с помощью npm --no-git-tag-version version для увеличения версии package.json внутри агента сборки без коммита, поэтомучто у вас нет изменений, вам придется вернуться к началу координат. Он должен просто изменить package.json и оставить его грязным.
Подождите, пока сборка завершится успешно. Используйте специальную задачу сценария для извлечения версии из package.json, затем git reset --hard (нет причин сохранять что-либо, что изменилось на сервере сборки). Хотя это отменит изменение в package.json, теперь вы можете создать тег на заголовке, который содержит эту версию, а затем выполнить git push origin {tag-name}, который не должен вводить новый коммит для источника, который затем повторно запустит ваш конвейер.
На самом деле, я не думаю конвейер будет запущен только потому, что был добавлен тег, но я, честно говоря, не проверял его. Я почти уверен, что это не так.
Последовательность задач в вашем конвейере:
[Учитывая исходное хранилище, где вы обязательно установили главную и вспомогательную версии в package.jsonчтобы отразить текущее состояние кода в соответствии с правилами семантического управления версиями и оставить значение патча всегда равным 0, и, если необходимо, использовать значения pre- * для описания качества основного / вспомогательного значения:]
- (Это на самом деле не задача, а просто описание начала выполнения :) Задание начинается. Код автоматически извлекается из исходного репозитория в агент сборки.
- Используя задание командной строки утилиты и код или сценарий, который вы пишете, запустите
git describe --tags, чтобы найти самый последний тег с tagname соответствует шаблону, который вы используете (см. ниже). (Я предпочитаю эту последовательность вместо вызова npm version from-git, потому что npm будет использовать только последний тег, который может не быть номером версии, в зависимости от того, насколько вы контролируете ветку.) Используйте операции с строками или регулярными выражениями для извлечения основного,несовершеннолетний, патч и все, что вы можете иметь до * значения. Это предыдущая версия, которую мы будем использовать для сравнения с тем, что находится в файле package.json. Обратите внимание, что вам, возможно, придется следовать этим инструкциям , чтобы запустить команду git. Сохраните его в переменную конвейера. . Используя задание командной строки утилиты и код или сценарий, который вы пишете, запустите npm version, чтобы получить текущий основной / вспомогательный / пре. версии из файла package.json и сохраните его в другой переменной конвейера. Я использую PowerShell Core, поэтому моя команда будет выглядеть примерно так для создания конвейерной переменной currentPackageVersion:
& npm.cmd version | ConvertFrom-Json | Select-Object -ExpandProperty {name-of-your-package} | Set-Variable -Name 'packageVersion' | Write-Output "#vso[task.setvariable variable=currentPackageVersion]$packageVersion"
Использование служебной задачи командной строки и кода или сценариячто вы пишете, сравните основные, вспомогательные и предыдущие значения предыдущей версии, чтобы определить, изменились ли какие-либо из них. Установите новую переменную конвейера, чтобы отразить, изменилась она или нет. Я буду использовать имя restartVersionPatchNumber, которое имеет значение true, если текущие основные, второстепенные или пре * значения отличаются от значений основной, минорной или пре * предыдущей версии.
- Задача npm условно запускает пользовательскую команду:
npm --no-git-tag-version version patch, которая обновляет package.json в агенте сборки, но не фиксирует изменения, оставляя вашу рабочую область измененной (грязной) (что может вызвать проблемы при последующих сборках, если вы используете свои собственные агенты сборки вместо размещенных агентов). В выражении условие Задачи используется пользовательское условие , которое оценивает в переменную , которую я только что установил на предыдущем шаге ("restartVersionPatchNumber"). Обратите внимание, что если эта задача не выполняется, она должна просто использовать значение версии, которая находится в файле package.json (текущая версия, которая теперь находится в переменной конвейера «currentPackageVersion»). - Используя служебную задачу командной строки и код или сценарий, который вы пишете, запустите
npm version, чтобы извлечь новую версию, заданную командой версии npm. Сохраните его в новую переменную конвейера;Я назову его «newVersionNumber». - Обычные задачи сборки запускаются, производят артефакты и, возможно, публикуют их
- Используя служебную задачу командной строки, запускайте
git reset --hard. Вам нужно будет сделать это, даже если вы используете размещенный агент сборки, из-за следующего шага. - Используя задачу командной строки утилиты, создайте переменную из сохраненного номера версии ("newVersionNumber"), который содержит значение тега tagname , который вы хотите использовать. Используйте отличительный шаблон, такой как «AzPipelineBuild-PipelineName-PackageVersion-1.0.0», но используйте свою версию вместо 1.0.0.
- Используя служебную задачу командной строки, запустите
git tag {*tagname*}. Для PowerShell синтаксис будет & git.exe tag $env:newVersionNumber - Используя задачу командной строки утилиты, запустите
git push origin {*tagname*} - Прибыль
Вы можете (и, возможно, должны) объединить шаги командной строки. Я действительно неравнодушен к задаче PowerShell, выполняющей PowerShellCore (pwsh), как вы уже догадались.
Пакет, созданный в качестве артефакта задания, будет иметь обновленную версию в том виде, как он был создан в сборке,и он будет соответствовать тегу, который сейчас находится в исходном репо исходного кода.
Альтернативно, используйте внешний источник (функция Azure и т. д.) или другой (второй) репозиторий git или даже другойветвь, которая не привязана к вашему триггеру CI в вашем проекте, который вы используете только для отслеживания номеров сборки, затем используйте задачи замены токена, чтобы установить версию непосредственно перед началом сборки. Мне не очень нравится эта идея, но она предотвратит повторный запуск новой сборки.
Кроме того, вы надеетесь собрать только один пакет с этим репо. Следующее, что нужно сделать, это опубликовать этот пакет в вашем фиде артефактов Azure, или на npmjs.org, или где угодно. Не полагайтесь на то, что версия встроена в исходный код;все, что зависит от этого пакета, должно извлекать его из того канала, на котором вы его опубликовали, не полагаясь на то, что он был собран ранее на этапах сборки с новым номером версии.