Ищете способ автоматизировать "рельефную версию" с потоком git
Я использую поток git в течение нескольких месяцев, и он работал очень хорошо. Я хотел бы автоматизировать операцию "bump version".
Проект представляет собой PHP, а footer.php имеет токен для замены тегом текущей версии. Я уверен, что с некоторым awk'ing git log и PHP файла все должно получиться, но я предполагаю, что кто-то сделал это раньше...
Любые идеи?
Ответы
Ответ 1
Вы можете использовать драгоценный камень semver, который добавляет файл .semver
в корень вашего репозитория git. Семантические номера версий являются рекомендацией для наличия структурированных/согласованных/значимых номеров версий, этот камень просто упрощает реализацию.
Итак, все, что вам нужно сделать, это добавить:
semver inc major|minor|patch
в ваш рабочий процесс (вручную или сценарий), чтобы обновить .semver во время выпуска.
Если вам не нужна зависимость ruby, semver довольно прост, так что немного экспериментов с sed, скорее всего, даст рабочее решение.
Ответ 2
В моем разветвленном проекте git -flow я фактически реализовал крючки и фильтры, запрос, который многие сделали в исходном проекте, но до сих пор не реализован. С помощью этих функций вы можете автоматически обновлять номера версий в своем проекте.
Разветвленный проект можно найти здесь
https://github.com/petervanderdoes/gitflow
Для некоторых скриптов Bash при запуске версии вы можете проверить два созданных мною gists
https://gist.github.com/2877083 или
https://gist.github.com/2878492
Ответ 3
Там также bumpversion (подробнее на https://github.com/peritus/bumpversion), цель которого - заменить эту магию sed.
Установите с помощью pip install bumpversion
, сообщите, какие файлы содержат номер вашей версии, и хотите ли вы их зафиксировать и пометить. Он также может быть сконфигурирован (с семантическим версированием по умолчанию), поэтому вы можете добавить декларативный файл конфигурации о том, как удалять версии для этого программного проекта в соответствии с вашими выборами, а другие также могут создавать версии.
Ответ 4
Веб-страница Semver гласит:
Учитывая номер версии MAJOR.MINOR.PATCH, увеличьте значение:
- ОСНОВНАЯ версия, когда вы делаете несовместимые изменения API,
- Версия MINOR, когда вы добавляете функциональность обратно совместимым образом и
- PATCH, когда вы делаете исправления ошибок с обратной совместимостью.
Дополнительные метки для метаданных до выпуска и сборки доступны как расширения в формате MAJOR.MINOR.PATCH.
Gitflow использует соглашение об именах для веток, исправления ошибок живут в ветвях с префиксом hotfix/
, а новые функции имеют префикс feature/
.
Когда какая-либо ветвь этого типа объединяется в ветвь освобождения, это приводит к увеличению PATCH
. Если функция была объединена, поле MINOR должно быть увеличено.
Учитывая конкретную ревизию, вы должны иметь возможность определить, была ли объединена одна из ветвей и какое поле было удалено.
Жесткая часть выясняет нарушение. Раньше я рассматривал использование рефлексии для скомпилированного кода, чтобы определить, изменился ли API, однако я полагаю, что было бы намного проще использовать ключевое слово в сообщениях фиксации, чтобы назначать нарушения.
Ответ 5
Вот код, который мы используем для увеличения номера версии в константах .h:
constants='../Include/constants.h'
# Get the current build number
currentbuild=`grep PRODUCT_BUILD $constants|sed 's/[^0-9]//g'`
currentversion=`grep PRODUCT_VERSION $constants|sed 's/[^.0-9]//g'`
echo "currentbuild=$currentbuild and currentversion=$currentversion"
newver=$((1+$currentbuild))
# Update the build number on-disk:
cp $constants /tmp/constants
if sed -e "/PRODUCT_BUILD/ s/[0-9][0-9]*/${newver}/" < /tmp/constants > $constants
then
echo "Updated build number from $currentversion.$currentbuild to $currentversion.$newver."
cd ../Include
# Check it into version control
svn ci -m "updated build number to ${currentversion}.${newver} for $buildid in $buildroot"
else
echo "There was a problem updating $constants to build $newver"
fi
Ответ 6
Вы также можете взглянуть на мое репо для bumpversion, которое в настоящее время сделано для файлов настройки python, которые можно изменить "Использование -bumpversion-package"
Ответ 7
Вы можете автоматизировать перегрузку каждой транзакции.
Здесь вы можете найти его, используя оболочку script и встроенный git hook:
https://github.com/addonszz/Galileo/tree/develop/githooks
Сценарий оболочки для запуска:
https://github.com/evandrocoan/.versioning/blob/master/scripts/updateVersion.sh
Проблема автоматизации каждого заключается в том, как узнать, обновляете ли вы майор, малый, патч или сборку, когда вы совершаете все.
Я имею в виду, что для сборки вы можете автоматизировать каждое завершение ветки развития, как это сделано в приведенной выше ссылке.
Патч, вы можете подключить каждое исправление потока git. В приведенной выше ссылке не хватает возможности перехватить исправление, чтобы увеличить версию исправления:
./githooks/updateVersion.sh patch
Но второстепенный и главный не трюк, все они сделаны в выпуске финиша.
набл
Я нашел решение для подключения pre-hotfix-commits, на вопрос:
Как завершить исправление исправления gitflow?
Ответ 8
Если я правильно понимаю вашу работу "bump version", вы подразумеваете увеличение номера версии в произвольном количестве файлов после того, как вы начали выпуск с git flow release start x.x.x
, где версия также представлена в теге git.
Поскольку исходный git -поток из Driessen был прекращен, неофициальным преемником, кажется, является Питер ван дер Ли gitflow-avh
(https://github.com/petervanderdoes/gitflow-avh/), который содержит большое количество крючков потока git. См. https://github.com/petervanderdoes/gitflow-avh/tree/develop/hooks для полного списка.
Я сделал версию на b post-flow-release-start
с помощью этого небольшого script:
VERSION=$1
# Get rid of version prefix
STRIPPED_VERSION=`echo $VERSION | cut -d'v' -f 2`
sed -i '' -E "s/^([ |#|[:alpha:]]*)\[.*\]$/\1[$STRIPPED_VERSION]/1" ./README.md
sed -i '' -E "s/^([\t| ]*\"version\": )\".*\"/\1\"$STRIPPED_VERSION\"/1" ./package.json
git commit -a -m "version $STRIPPED_VERSION"
exit 0
Это немного жестко, потому что два файла жестко запрограммированы (README.md и package.json). Вы можете выполнить поиск старой версии из последнего тега, а затем повторить ее для всех сконфигурированных файлов в цикле.
Предостережения:
OSX требует суффикса для sed -i
, однако вы можете использовать пустые кавычки. Кроме того, расширенный параметр регулярного выражения для sed
по-разному указан в Linux.