RMT
1.0.0
RMT es una herramienta útil para ayudar a lanzar nuevas versiones de su software. Puede definir el tipo de generador de versiones que desea usar (por ejemplo, versiones semánticas), donde desea almacenar la versión (por ejemplo, en un archivo ChangeLog o como una etiqueta VCS) y una lista de acciones que deben ejecutarse antes o después del Lanzamiento de una nueva versión.
Para usar RMT en su proyecto, debe usar el compositor para instalarlo como una dependencia de Dev. Simplemente vaya al directorio raíz de su proyecto y ejecute:
composer require --dev liip/rmt
Entonces debe inicializar RMT ejecutando el siguiente comando:
php vendor/liip/rmt/command.php init
Este comando creará un archivo de configuración .rmt.yml y un script ejecutable RMT en la carpeta raíz de su proyecto. Ahora puede comenzar a usar RMT ejecutando:
./RMT
Una vez allí, su mejor opción es elegir uno de los ejemplos de configuración a continuación y adaptarlo a sus necesidades.
Si está utilizando una herramienta de versiones, recomendamos agregar ambos archivos compositor ( composer.json y composer.lock ), el archivo de configuración RMT ( .rmt.yml ) y el script ejecutable de RMT . El directorio vendor debe ignorarse a medida que se pobla cuando se ejecuta composer install .
Puede agregar RMT a su Global Composer.json y tenerlo disponible a nivel mundial para todos sus proyectos. Por lo tanto, solo ejecute el siguiente comando:
composer global require liip/rmt
Asegúrese de tener ~/.composer/vendor/bin/ en su ruta $.
RMT se puede instalar a través del compositor PHAR, que debe instalarse para el mismo. Esta útil herramienta le permite crear archivos PHAR ejecutables a partir de paquetes compositor.
Si tiene instalado Phar-Composer, puede ejecutar:
sudo phar-composer install liip/RMT
y haga que Phar-Composer construya e instale el archivo PHAR en su ruta $, que luego le permite ejecutarlo simplemente como rmt desde la línea de comandos o puede ejecutar
phar-composer build liip/RMT
y copie el archivo PHAR resultante manualmente a donde lo necesite (haga el ejecutable del archivo PHAR a través de chmod +x rmt.phar y ejecutelo directamente ./rmt.phar o ejecutarlo invocando a través de PHP a través de php rmt.phar .
Para el uso de RMT de sustituto de uso con cualquier variante que haya decidido usar.
Si está utilizando https://github.com/liip/drifter para su proyecto, solo necesita tres pasos
Activar el papel rmt
Vuelva a ejecutar la vagrant provision de aprovisionamiento
Init RMT para su proyecto php /home/vagrant/.config/composer/vendor/liip/rmt/RMT
Usar RMT es muy sencillo, simplemente ejecute el comando:
./RMT release
RMT luego ejecutará las siguientes tareas:
Ejecutar las comprobaciones de requisitos previos
Solicite al usuario que responda preguntas potenciales
Ejecutar las acciones de prelanzamiento
Liberar
Generar un nuevo número de versión
Persistir el nuevo número de versión
Ejecutar las acciones posteriores a la liberación
Aquí hay una salida de ejemplo:
El comando release proporciona el comportamiento principal de la herramienta, están disponibles algunos comandos adicionales:
current mostrará el número de versión actual de su proyecto (versión de alias)
changes muestran los cambios que se incorporarán en la próxima versión
config Muestra la configuración actual (ya fusionada)
init crea (o restablece) el archivo de configuración .rmt.yml
Todas las configuraciones RMT deben hacerse en .rmt.yml . El archivo se divide en seis elementos raíz:
vcs : el tipo de VCS que está utilizando, puede ser git , svn o none
Para git VCS, puede usar las dos opciones siguientes sign-tag y sign-commit si desea GPG firmar su lanzamiento
prerequisites : una lista [] de requisitos previos que deben coincidir antes de comenzar el proceso de lanzamiento
pre-release-actions : una lista [] de acciones que se ejecutarán antes del proceso de liberación
version-generator : el generador que se utilizará para crear una nueva versión (obligatoria)
version-persister : el Persister para usar para almacenar las versiones (obligatorias)
post-release-actions : una lista [] de acciones que se ejecutarán después de la versión
Todas las entradas de esta configuración funcionan igual. Debe especificar la clase que desea manejar la acción. Ejemplo:
version-generator: "simple"` version-persister: vcs-tag: tag-prefix: "v_"
RMT también admite las configuraciones de JSON, pero recomendamos usar YAML.
A veces desea utilizar una estrategia de lanzamiento diferente de acuerdo con la rama VCS, por ejemplo, desea agregar entradas ChangeLog solo en la rama master . Para hacerlo, debe colocar su configuración predeterminada en un elemento raíz llamado _default , luego puede anular partes de esta configuración predeterminada para el master de rama. Ejemplo:
_default: version-generator: "simple" version-persister: "vcs-tag" master: pre-release-actions: [changelog-update]
Puede usar la RMT config de comando para ver el resultado de fusión entre _default y su rama actual.
Estrategias de generación de números de versión incorporados.
Simple: este generador está haciendo un incremento simple (1,2,3 ...)
Semántico: un generador que implementa versiones semánticas
Las dos opciones forzadas podrían ser muy útiles si decide que una rama dada está dedicada a la próxima versión beta de una versión dada. Entonces, solo obliga a la etiqueta a beta y a todos los lanzamientos serán incrementos beta.
Opción allow-label (boolean): para permitir agregar una etiqueta en una versión (como -beta, -rcxx) (predeterminado: falso )
type de opción: para forzar el tipo de versión
label de opción: para forzar la etiqueta
Clase a cargo de guardar/recuperar el número de versión.
VCS-TAG: Guarde la versión como una etiqueta VCS
Opción tag-pattern : deje proporcionar una regex que toda la etiqueta debe coincidir. Esto permite, por ejemplo, lanzar una versión 1.xx en una rama específica y liberar un 2.xx en una rama separada
Opción tag-prefix : Deje prefijo todas las etiquetas VCS con una cadena. Puede tener una versión numérica pero etiquetas de generación como v_2.3.4 . Como bono, puede usar un marcador de posición específico: {branch-name} que inyectará automáticamente el nombre de la rama actual en la etiqueta. Así que use, generación simple y tag-prefix: "{branch-name}_" y generará etiquetas como featureXY_1 , featureXY_2 , etc ...
ChangeLog: Guarde la versión en el archivo ChangeLog
Opción location : Nombre del archivo ChangeLog Una ubicación (predeterminado: ChangeLog )
Las acciones previas se ejecutan antes de la parte interactiva.
working-copy-check : verifique que no tenga cambios locales de VCS
Opción allow-ignore --ignore-check
display-last-changes : Muestre sus últimos cambios
tests-check : ejecute la suite de prueba del proyecto
command de opción: comando para ejecutar (predeterminado: phpunit )
timeout de opción: el número de segundos después de los cuales el comando sale de la hora (predeterminado: 60.0 )
Opción expected_exit_code : código de retorno esperado (predeterminado: 0 )
composer-json-check : ejecute un validar en el compositor.json
composer de opciones: Cómo ejecutar el compositor (predeterminado: php composer.phar )
composer-stability-check : verificará si el composer.json está configurado con la estabilidad mínima correcta
stability de la opción: la estabilidad que debe establecerse en el campo de estabilidad mínima (predeterminado: estable )
composer-security-check : ejecute Composer.lock contra https://github.com/fabpot/local-php-security-checker para verificar las vulnerabilidades conocidas en las dependencias.
El binario local-Security-Checker debe instalarse a nivel mundial.
composer-dependency-stability-check : prueba si solo las dependencias permitidas utilizan versiones de desarrollo
Opción ignore-require e ignore-require-dev : No verifique las dependencias en la sección require o require-dev
Opción whitelist : Permitir dependencias específicas para usar la versión de desarrollo
command : ejecute un comando de sistema
Opción cmd el comando para ejecutar
Opción live_output boolean, ¿mostramos la salida del comando? (predeterminado: verdadero )
Opción timeout entero, limita el tiempo para el comando. (predeterminado: 600 )
Opción stop_on_error boolean, ¿rompemos el proceso de liberación en error? (predeterminado: verdadero )
Las acciones se pueden usar para piezas de liberación previa o posterior.
changelog-update : actualice un archivo ChangeLog. Esta acción está configurada para usar un formato específico.
format de opción: simple , semántico , markdown o addtop (predeterminado: simple )
file de opción: ruta de .rmt.yml a ChangeLog File (predeterminado: ChangeLog )
Opción dump-commits : escriba todos los mensajes de confirmación desde la última versión en el archivo ChangeLog (predeterminado: falso )
Opción insert-at : solo para AddTop Formatter: Número de líneas para omitir desde la parte superior del archivo ChangeLog antes de agregar el número de liberación (predeterminado: 0 )
Opción exclude-merge-commits : excluya las confirmaciones de fusiones del cambio de cambio (predeterminado: falso )
vcs-commit : confirme todos los archivos de la copia de trabajo (solo úselo con el requisito previo de la working-copy-check )
Opción commit-message : especifique un mensaje de confirmación personalizada. % La versión% será reemplazada por las cadenas de versión actual / siguiente.
vcs-tag : etiqueta el último comet
vcs-publish : publique los cambios (compromisos y etiquetas)
composer-update : actualice el número de versión en un archivo compositor (tenga en cuenta que cuando se usa Packagist.org, se recomienda no tener una etiqueta en composer.json, ya que la versión se maneja mediante etiquetas de control de versiones)
files-update : actualice la versión en uno o múltiples archivos. Para que cada archivo se actualice, proporcione una matriz con
file de opción: ruta al archivo para actualizar
pattern de opción: opcional, use para especificar el patrón de reemplazo de cadenas en su archivo. Por ejemplo: const VERSION = '%version%';
build-phar-package : construye un paquete PHAR del proyecto actual cuyo nombre de archivo depende de la opción 'Nombre de paquete' y de la versión implementada: [Nombre del paquete]-[Versión] .phar
package-name de opción: el nombre del paquete Generar
destination de opción: el directorio de destino para construir el paquete en. Si prefijo con un corte, se considera absoluto, de lo contrario en relación con la raíz del proyecto.
Opción excluded-paths : una regex de rutas excluidas, pasadas directamente al método Phar :: BuildFromDirectory. Ej: /^(?!.*cookbooks|.*.vagrant|.*.idea).*$/im
metadata de opción: una matriz de metadatos que describen el paquete. Ex autor, proyecto. Nota: La versión de lanzamiento se agrega de forma predeterminada, pero se puede anular aquí.
Opción default-stub-cli : el trozo predeterminado para el uso de CLI del paquete.
Opción default-stub-web : el trozo predeterminado para el uso de la aplicación web del paquete.
command : ejecute un comando de sistema
Opción cmd el comando para ejecutar
Opción live_output boolean, ¿mostramos la salida del comando? (predeterminado: verdadero )
Opción timeout entero, limita el tiempo para el comando. (predeterminado: 600 )
Opción stop_on_error boolean, ¿rompemos el proceso de liberación en error? (predeterminado: verdadero )
update-version-class : actualice la versión constante en un archivo de clase. Desapercibido, use files-update en su lugar
Opción class : ruta a la clase a actualizar o el nombre de clase totalmente calificado de la clase que contiene la versión constante
pattern de opción: opcional, use para especificar el patrón de reemplazo de cadena en su clase de versión. % La versión% será reemplazada por las cadenas de versión actual / siguiente. Por ejemplo, puede usar const VERSION = '%version%'; . Si no especifica esta opción, se reemplazará cada aparición de la cadena de versión en el archivo.
RMT proporciona algunas acciones, generadores y persistentes existentes. Si es necesario, puede agregar el suyo creando un script PHP en su proyecto y haciendo referencia en la configuración a través de su ruta relativa:
version-generator: "bin/myOwnGenerator.php"
Ejemplo con parámetros inyectados:
version-persister: name: "bin/myOwnGenerator.php" parameter1: value1
Como ejemplo, puede ver el script /bin/updataApplicationVersionCurrentVersion.php configurado aquí.
ADVERTENCIA: Como el name clave se usa para definir el nombre del objeto, no puede tener un parámetro llamado name .
La mayoría de las veces, será más fácil para usted elegir un ejemplo a continuación y adaptarlo a sus necesidades.
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-tagSi desea ayudar, enviando uno de sus scripts, generadores o persistentes de acción. O simplemente informando un error, simplemente vaya a la página del proyecto https://github.com/liip/rmt.
Si proporciona un PR, intente asociarlo alguna unidad o pruebas funcionales. Ver la siguiente sección
Para poder ejecutar las pruebas localmente, necesita:
phpunit
git
mercurial
Puede instalarlos todos con cerveza:
> brew install phpunit git hg
Las pruebas también están probando la creación del RMT PHAR. Así que debes permitir esto en tu php.ini, sin cometer esta línea:
phar.readonly = Off
Finalmente, para ejecutar las pruebas, simplemente inicie phpunit
> phpunit
Las pruebas funcionales son una configuración RMT temporal completamente funcional. Cada vez que ejecuta la prueba funcional, crea una carpeta temporal con un proyecto RMT. Luego, la suite de prueba está ejecutando comandos RMT y verifique los resultados. Es por eso que necesitas tener instalado Git y Mercurial.
Para depurar las pruebas funcionales RMT, lo mejor es entrar en esta carpeta temporal y explorar manualmente el proyecto. Para hacerlo, simplemente agregue un pequeño $this->manualDebug(); en la suite de prueba. Esto romperá la prueba con la siguiente salida:
MANUAL DEBUG Go to: > cd /private/var/folders/hl/gnj5dcj55gbc93pcgrjxbb0w0000gn/T/ceN2Mf
Entonces solo tienes que entrar en la carpeta mencionada y comenzar a depurar
Jonathan Macheret, Liip SA
David Jeanmonod Liip sa
y otros contribuyentes
RMT tiene licencia bajo la licencia MIT. Consulte el archivo de licencia para obtener más detalles.
