RMT
1.0.0
RMT - это удобный инструмент, который помогает выпустить новые версии вашего программного обеспечения. Вы можете определить тип генератора версий, который вы хотите использовать (например, Semantic Versionsing), где вы хотите сохранить версию (например, в файле ChangeLog или в виде тега VCS) и список действий, которые должны выполняться до или после Выпуск новой версии.
Чтобы использовать RMT в вашем проекте, вы должны использовать композитор для его установки в качестве зависимости от развития. Просто перейдите в корневой каталог вашего проекта и выполните:
composer require --dev liip/rmt
Затем вы должны инициализировать RMT, выполнив следующую команду:
php vendor/liip/rmt/command.php init
Эта команда создаст файл конфигурации .rmt.yml и исполняемый сценарий RMT в корневой папке вашего проекта. Теперь вы можете начать использовать RMT, выполнив:
./RMT
Оказавшись там, ваш лучший вариант - выбрать один из примеров конфигурации ниже и адаптировать его к вашим потребностям.
Если вы используете инструмент размещения версий, мы рекомендуем добавить оба файла Composer ( composer.json и composer.lock ), файл конфигурации RMT ( .rmt.yml ) и исполняемый сценарий RMT . Справочник vendor следует игнорировать, так как он заполняется при запуске composer install .
Вы можете добавить RMT в свой Global Composer.json и получить его во всем мире для всех ваших проектов. Поэтому просто запустите следующую команду:
composer global require liip/rmt
Убедитесь, что у вас есть ~/.composer/vendor/bin/ в вашем пути.
RMT может быть установлен через Phar-Composer, который должен быть установлен для этого. Этот полезный инструмент позволяет вам создавать файлы Phar -Phar из пакетов Composer.
Если у вас установлен фар-композитор, вы можете запустить:
sudo phar-composer install liip/RMT
и иметь фар-композитор и установить файл phar в свой путь $, который затем позволяет запустить его просто как rmt из командной строки или вы можете запустить
phar-composer build liip/RMT
и скопируйте полученный файл Phar вручную туда, где он вам нужен (либо сделайте файл phar, исполняемый через chmod +x rmt.phar , и выполните его напрямую ./rmt.phar либо запустите его, вызывая его через PHP через php rmt.phar .
Для заменителя использования RMT любым вариантом, который вы решили использовать.
Если вы используете https://github.com/liip/drifter для своего проекта, вам просто нужно три шага
Активировать роль rmt
Перезагрузка проведисного vagrant provision
Init rmt для вашего проекта php /home/vagrant/.config/composer/vendor/liip/rmt/RMT
Использование RMT очень просто, просто запустите команду:
./RMT release
RMT затем выполнит следующие задачи:
Выполнить проверки предпосылок
Попросите пользователя ответить на вопросы потенциальных вопросов
Выполнить предварительные действия
Выпускать
Создайте новый номер версии
Сохраняйте новый номер версии
Выполнить действия после освобождения
Вот пример вывода:
Команда release предоставляет основное поведение инструмента, доступны дополнительные дополнительные команды:
current покажет номер текущей версии вашего проекта (версия псевдонима)
changes отображают изменения, которые будут включены в следующее выпуск
config отображения текущей конфигурации (уже объединенная)
init создать (или сбросить) файл конфигурации .rmt.yml
Все конфигурации RMT должны быть сделаны в .rmt.yml . Файл разделен на шесть корневых элементов:
vcs : тип используемых вами VCS может быть git , svn или none
Для git VCS вы можете использовать два следующих параметра sign-tag и sign-commit если вы хотите, чтобы GPG подписывает свой релиз
prerequisites : список [] предпосылок, которые необходимо соответствовать перед началом процесса выпуска
pre-release-actions : список [] действий, которые будут выполнены до процесса выпуска
version-generator : генератор, который можно использовать для создания новой версии (обязательна)
version-persister : Персистера для хранения версий (обязательно)
post-release-actions : список [] действий, которые будут выполнены после выпуска
Все записи этой конфигурации работают одинаково. Вы должны указать класс, который вы хотите справиться с действием. Пример:
version-generator: "simple"` version-persister: vcs-tag: tag-prefix: "v_"
RMT также поддерживает конфигурации JSON, но мы рекомендуем использовать YAML.
Иногда вы хотите использовать другую стратегию выпуска в соответствии с филиалом VCS, например, вы хотите добавить записи изменений в master -филиале. Для этого вы должны поместить конфигурацию по умолчанию в корневой элемент с именем _default , затем вы можете переопределить части этой конфигурации по умолчанию для Manage master . Пример:
_default: version-generator: "simple" version-persister: "vcs-tag" master: pre-release-actions: [changelog-update]
Вы можете использовать RMT config чтобы увидеть результат слияния между _default и вашей текущей ветвей.
Стратегии генерации номеров версий.
Просто: этот генератор делает простой прирост (1,2,3 ...)
Семантика: генератор, который реализует семантическую версию
Два принудительного варианта может быть очень полезна, если вы решите, что данная филиала посвящена следующей бета -версии данной версии. Так что просто заставили этикетку к бета -версии, и все выпуск будет бета -шагом.
Опция allow-label (boolean): чтобы позволить добавить метку в версию (например, -beta, -rcxx) (по умолчанию: false )
type опции: чтобы заставить тип версии
Опционная label : чтобы заставить этикетку
Класс, отвечающий за сохранение/получение номера версии.
VCS-TAG: Сохраните версию в качестве тега VCS
Опция tag-pattern : разрешить предоставить регулярность, которую должен соответствовать все теги. Это позволяет, например, выпустить версию 1.xx в определенной ветви и выпустить 2.xx в отдельной филиале
Опция tag-prefix : разрешить префиксу все теги VCS с помощью строки. Вы можете иметь цифровой серию, но теги поколения, такие как v_2.3.4 . В качестве бонуса вы можете использовать конкретный заполнитель: {branch-name} , который автоматически внедрит текущее имя ветви в тег. Итак, используйте, простой генерация и tag-prefix: "{branch-name}_" и он будет генерировать теги, как featureXY_1 , featureXY_2 и т. Д.
ChangeLog: Сохраните версию в файле ChangeLog
location параметра: Имя файла Changelog местоположение (по умолчанию: Changelog )
Обязательные действия выполняются до интерактивной части.
working-copy-check : Проверьте, что у вас нет никаких венчурных локальных изменений
Опция allow-ignore : позвольте пользователю пропустить чек при выпуске с помощью --ignore-check
display-last-changes : отображение последних изменений
tests-check : запустите набор тестов Project
command параметра: команда для запуска (по умолчанию: phpunit )
timeout опции: количество секунд, после чего команда времени выходит (по умолчанию: 60.0 )
Опция expected_exit_code : ожидаемый код возврата (по умолчанию: 0 )
composer-json-check : запустите проверку на Composer.json
Опция composer : Как запустить Composer (по умолчанию: php composer.phar )
composer-stability-check : проверьте, устанавливается ли Composer.json на правильную минимальную стабильность
stability опции: стабильность, которая должна быть установлена в поле минимальной стабильности (по умолчанию: стабильно )
composer-security-check : запустите Composer.lock против https://github.com/fabpot/local-php-security-checker, чтобы проверить известные уязвимости в зависимостях.
Двоиц локальной проверки-метеорологической безопасности должен быть установлен во всем мире.
composer-dependency-stability-check : тест, если только разрешенные зависимости используются версии разработки
Опция ignore-require и ignore-require-dev : не проверяйте зависимости в require или require-dev .
Вариант whitelist : Позвольте конкретным зависимостям использовать версию разработки
command : выполнить системную команду
Опция cmd команда для выполнения
Опция live_output Boolean, отображаем ли мы команды? (по умолчанию: true )
Опция timeout целое число, ограничивает время для команды. (По умолчанию: 600 )
Опция stop_on_error boolean, мы разбиваем процесс выпуска по ошибке? (по умолчанию: true )
Действия могут использоваться для частей до или после выпуска.
changelog-update : обновить файл ChangeLog. Это действие дополнительно настроено для использования конкретного форматера.
format опции: простой , семантический , разметка или добавление (по умолчанию: просто )
file опции: Путь от .rmt.yml в файл изменений (по умолчанию: Changelog )
Опция dump-commits : запишите все сообщения о коммите после последнего выпуска в файл Changelog (по умолчанию: false )
Опция insert-at : только для форматерата AddTop: количество строк, чтобы пропустить из верхней части файла ChangeLog перед добавлением номера выпуска (по умолчанию: 0 )
Опция exclude-merge-commits : Exclude Merge Commits из ChangeLog (по умолчанию: false )
vcs-commit : COMMEAR FILEST WORPER COPY (используйте ее только с обязательным условием working-copy-check )
Опция commit-message : укажите пользовательское сообщение о коммите. % Версия% будет заменена на текущие / следующие строки версии.
vcs-tag : отметьте последний коммит
vcs-publish : опубликовать изменения (коммиты и теги)
composer-update : Обновите номер версии в файле композитора (обратите внимание, что при использовании packagist.org рекомендуется не иметь тега в composer.json, поскольку версия обрабатывает теги управления версией)
files-update : обновите версию в одном или нескольких файлах. Для каждого файла для обновления, пожалуйста, предоставьте массив с
file опции: Путь к файлу для обновления
Опция pattern : необязательно, используйте для указания шаблона замены строки в вашем файле. Например: const VERSION = '%version%';
build-phar-package : создает пакет PHAR текущего проекта, чье имя файла зависит от опции «Пакет-имени» и развернутой версии: [Package-name]-[версия] .Phar
Опции package-name : Имя пакета Generate
Опция destination : каталог назначения для создания пакета. Если префикс с помощью удара, считается абсолютным, в противном случае относительно корня проекта.
Опция excluded-paths : регулярность исключенных путей, непосредственно передаваемой методу Phar :: BuildfromDirectory. Пример: /^(?!.*cookbooks|.*.vagrant|.*.idea).*$/im
metadata опции: массив метаданных, описывающих пакет. Бывший автор, проект. Примечание. Версия для выпуска добавлена по умолчанию, но может быть переопределена здесь.
Опция default-stub-cli : заглушка по умолчанию для использования CLI пакета.
Опция default-stub-web : заглушка по умолчанию для использования веб-приложения пакета.
command : выполнить системную команду
Опция cmd команда для выполнения
Опция live_output Boolean, отображаем ли мы команды? (по умолчанию: true )
Опция timeout целое число, ограничивает время для команды. (По умолчанию: 600 )
Опция stop_on_error boolean, мы разбиваем процесс выпуска по ошибке? (по умолчанию: true )
update-version-class : обновите постоянную версию в файле класса. Устарел, используйте files-update вместо этого
class опций: Путь к классу, который будет обновлен, или полностью квалифицированное имя класса класса, содержащее версию
Опция pattern : необязательно, используйте для указания шаблона замены строки в классе версии. % Версия% будет заменена на текущие / следующие строки версии. Например, вы можете использовать const VERSION = '%version%'; Полем Если вы не указали эту опцию, каждое появление строки версии в файле будет заменено.
RMT предоставляет некоторые существующие действия, генераторы и персистры. При необходимости вы можете добавить свой собственный, создав сценарий PHP в вашем проекте и ссылались на его в конфигурации по его относительному пути:
version-generator: "bin/myOwnGenerator.php"
Пример с инъекционными параметрами:
version-persister: name: "bin/myOwnGenerator.php" parameter1: value1
В качестве примера вы можете посмотреть на Script /bin/updateapplicationVersionCurrentVersion.php, настроенный здесь.
Предупреждение: поскольку name ключа используется для определения имени объекта, у вас не может быть name параметр с именем.
В большинстве случаев вам будет легче забрать пример ниже и адаптировать его к вашим потребностям.
version-generator: semantic version-persister: changelog
vcs: git version-generator: simple version-persister: vcs-tag prerequisites: [working-copy-check, display-last-changes]
vcs: git version-generator: simple version-persister: vcs-tag prerequisites: - composer-json-check - composer-stability-check: stability: beta - composer-dependency-stability-check: whitelist: - [symfony/console] - [phpunit/phpunit, require-dev]
vcs: name: git sign-tag: true sign-commit: true version-generator: simple version-persister: vcs-tag prerequisites: [working-copy-check, display-last-changes]
vcs: git version-generator: semantic version-persister: name: vcs-tag tag-prefix : "v_" pre-release-actions: files-update: - [config.yml] - [app.ini, 'dynamic-version: %version%'] post-release-actions: [vcs-publish]
_default:
vcs: git
prerequisites: [working-copy-check]
version-generator: simple
version-persister:
name: vcs-tag
tag-prefix: "{branch-name}_"
post-release-actions: [vcs-publish]
# This entry allow to override some parameters for the master branch
master:
prerequisites: [working-copy-check, display-last-changes]
pre-release-actions:
changelog-update:
format: markdown
file: CHANGELOG.md
dump-commits: true
update-version-class:
class: DoctrineODMPHPCRVersion
pattern: const VERSION = '%version%';
vcs-commit: ~
version-generator: semantic
version-persister: vcs-tagЕсли вы хотите помочь, отправив один из ваших сценариев действий, генераторов или персистенсов. Или просто сообщив об ошибке, просто перейдите на страницу проекта https://github.com/liip/rmt.
Если вы предоставите PR, попробуйте связать его с некоторыми модуль или функциональными тестами. Смотрите следующий раздел
Чтобы иметь возможность запустить тесты локально, вам нужно:
Phpunit
git
ртутный
Вы можете установить их все с помощью варева:
> brew install phpunit git hg
Тесты также тестируют создание RMT Phar. Таким образом, вы должны разрешить это в своем php.ini, не покинув эту линию:
phar.readonly = Off
Наконец, чтобы запустить тесты, просто запустите Phpunit
> phpunit
Функциональные тесты являются полностью функциональной временной настройкой RMT. Каждый раз, когда вы запускаете функциональный тест, он создает временную папку с проектом RMT. Затем тестовый набор запускает команды RMT на нем и проверяйте результаты. Вот почему вам нужно установить git и mercurial.
Чтобы отлаживать функциональные тесты RMT, лучше всего перейти в эту временную папку и вручную изучить проект. Для этого просто добавьте небольшую $this->manualDebug(); в испытательный набор. Это нарушит тест со следующим выходом:
MANUAL DEBUG Go to: > cd /private/var/folders/hl/gnj5dcj55gbc93pcgrjxbb0w0000gn/T/ceN2Mf
Тогда вам просто нужно перейти в упомянутую папку и начать отладку
Джонатан Мачерет, Liip SA
Дэвид Жанмонод Liip SA
и другие участники
RMT лицензирован по лицензии MIT. Смотрите файл лицензии для получения подробной информации.
