RMT
1.0.0
RMT est un outil pratique pour aider à publier de nouvelles versions de votre logiciel. Vous pouvez définir le type de générateur de version que vous souhaitez utiliser (par exemple, les versioning sémantique), où vous souhaitez stocker la version (par exemple dans un fichier changelog ou en tant que balise VCS) et une liste d'actions qui devraient être exécutées avant ou après le version d'une nouvelle version.
Afin d'utiliser RMT dans votre projet, vous devez utiliser Composer pour l'installer comme dépendance de développement. Accédez simplement au répertoire racine de votre projet et exécutez:
composer require --dev liip/rmt
Alors vous devez initialiser RMT en exécutant la commande suivante:
php vendor/liip/rmt/command.php init
Cette commande créera un fichier de configuration .rmt.yml et un script exécutable RMT dans le dossier racine de votre projet. Vous pouvez maintenant commencer à utiliser RMT en exécutant:
./RMT
Une fois sur place, votre meilleure option est de choisir l'un des exemples de configuration ci-dessous et de l'adapter à vos besoins.
Si vous utilisez un outil de versioning, nous vous recommandons d'ajouter à la fois des fichiers compositeurs ( composer.json et composer.lock ), le fichier de configuration RMT ( .rmt.yml ) et le script exécutable RMT . Le répertoire vendor doit être ignoré car il est rempli lors de l' composer install .
Vous pouvez ajouter RMT à votre Global Composer.json et le mettre disponible dans le monde pour tous vos projets. À ce moment-là, exécutez la commande suivante:
composer global require liip/rmt
Assurez-vous d'avoir ~/.composer/vendor/bin/ dans votre chemin $.
RMT peut être installé via Phar-Composer, qui doit y être installé. Cet outil utile vous permet de créer des fichiers Phar Runnable à partir de packages de compositeurs.
Si un compositeur phar-composeur, vous pouvez courir:
sudo phar-composer install liip/RMT
et avoir une construction phar-compositeur et installer le fichier phar sur votre chemin $, qui vous permet ensuite de l'exécuter simplement en tant que rmt à partir de la ligne de commande ou vous pouvez exécuter
phar-composer build liip/RMT
et copiez manuellement le fichier Phar résultant à l'endroit où vous en avez besoin (faites le fichier phar exécutable via chmod +x rmt.phar et exécutez-le directement ./rmt.phar ou exécutez-le en l'invoquant via PHP via php rmt.phar .
Pour le remplacement d'utilisation RMT avec la variante que vous avez décidé d'utiliser.
Si vous utilisez https://github.com/liip/drifter pour votre projet, vous avez juste besoin de trois étapes
Activer le rôle rmt
Re-piste la disposition vagrant provision
Init rmt pour votre projet php /home/vagrant/.config/composer/vendor/liip/rmt/RMT
L'utilisation de RMT est très simple, il suffit d'exécuter la commande:
./RMT release
RMT exécutera ensuite les tâches suivantes:
Exécuter les contrôles préalables
Demandez à l'utilisateur de répondre aux questions des potentiels
Exécuter les actions de pré-libération
Libérer
Générer un nouveau numéro de version
Persister le nouveau numéro de version
Exécuter les actions post-libération
Voici un exemple de sortie:
La commande release fournit le comportement principal de l'outil, certaines commandes supplémentaires sont disponibles:
current affichera votre projet Numéro de version actuelle (version Alias)
changes affichent les modifications qui seront incorporées dans la prochaine version
config Affichez la configuration actuelle (déjà fusionnée)
init Créer (ou réinitialiser) le fichier de configuration .rmt.yml
Toutes les configurations RMT doivent être effectuées dans .rmt.yml . Le fichier est divisé en six éléments racine:
vcs : Le type de VC que vous utilisez peut être git , svn ou none
Pour git VCS, vous pouvez utiliser les deux options suivantes sign-tag et sign-commit si vous souhaitez signer GPG votre version
prerequisites : une liste [] des conditions préalables qui doivent être appariées avant de commencer le processus de publication
pre-release-actions : une liste [] des actions qui seront exécutées avant le processus de libération
version-generator : le générateur à utiliser pour créer une nouvelle version (obligatoire)
version-persister : The Persister à utiliser pour stocker les versions (obligatoire)
post-release-actions : une liste [] des actions qui seront exécutées après le communiqué
Toutes les entrées de cette configuration fonctionnent de la même manière. Vous devez spécifier la classe que vous souhaitez gérer l'action. Exemple:
version-generator: "simple"` version-persister: vcs-tag: tag-prefix: "v_"
RMT prend également en charge les configurations JSON, mais nous vous recommandons d'utiliser YAML.
Parfois, vous souhaitez utiliser une stratégie de libération différente en fonction de la branche VCS, par exemple, vous souhaitez ajouter des entrées de modification uniquement dans la branche master . Pour ce faire, vous devez placer votre configuration par défaut dans un élément racine nommé _default , vous pouvez ensuite remplacer les parties de cette configuration par défaut pour le master de la branche. Exemple:
_default: version-generator: "simple" version-persister: "vcs-tag" master: pre-release-actions: [changelog-update]
Vous pouvez utiliser la RMT config de commande pour voir le résultat de la fusion entre _default et votre branche actuelle.
Stratégies de génération de numéros de version intégrée.
Simple: ce générateur fait un simple incrément (1,2,3 ...)
Sémantique: un générateur qui implémente le versioning sémantique
L'option forcée pourrait être très utile si vous décidez qu'une branche donnée est dédiée à la prochaine version bêta d'une version donnée. Donc, forcez simplement l'étiquette à la version bêta et toutes les libérations vont être des incréments bêta.
Option allow-label (Boolean): Pour permettre d'ajouter une étiquette sur une version (comme -Beta, -rcxx) (par défaut: false )
type d'option: pour forcer le type de version
label d'option: pour forcer l'étiquette
Classe en charge de l'enregistrement / récupération du numéro de version.
VCS-TAG: Enregistrez la version en tant que balise VCS
Option tag-pattern : permettez de fournir un regex que toutes les balises doivent correspondre. Cela permet par exemple de publier une version 1.xx dans une branche spécifique et de libérer un 2.xx dans une branche séparée
Option tag-prefix : permettez de préfixer toutes les balises VCS avec une chaîne. Vous pouvez avoir une version numérique mais des balises de génération telles que v_2.3.4 . En tant que bonus, vous pouvez utiliser un espace réservé spécifique: {branch-name} qui injectera automatiquement le nom de branche actuel dans la balise. Utilisez donc, génération simple et tag-prefix: "{branch-name}_" et il générera une balise comme featureXY_1 , featureXY_2 , etc ...
ChangeLog: Enregistrez la version dans le fichier Changelog
location de l'option: Nom du fichier ChangeLog Un emplacement (par défaut: ChangeLog )
Les actions préalables sont exécutées avant la partie interactive.
working-copy-check : Vérifiez que vous n'avez pas de modifications locales VCS
Option allow-ignore : permettez à l'utilisateur de sauter le chèque lors d'une version avec --ignore-check
display-last-changes : affichez vos derniers modifications
tests-check : Exécutez la suite de tests de projet
command d'option: commande à exécuter (par défaut: phpunit )
timeout d'option: le nombre de secondes après quoi les temps de commande sont sortis (par défaut: 60.0 )
Option expected_exit_code : code de retour attendu (par défaut: 0 )
composer-json-check : Exécutez un validation sur le compositeur.json
Option composer : Comment exécuter Composer (par défaut: PHP Composer.phar )
composer-stability-check : Vérifiera si le composer.json est défini sur la bonne stabilité minimale
stability d'option: la stabilité qui doit être définie dans le champ de stabilité minimum (par défaut: stable )
composer-security-check : exécutez le composer.lock contre https://github.com/fabpot/local-php-security-checker pour vérifier les vulnérabilités connues dans les dépendances.
Le binaire local-php-security-checker doit être installé à l'échelle mondiale.
composer-dependency-stability-check : tester si seulement les dépendances autorisées utilisent des versions de développement
Option ignore-require et ignore-require-dev : Ne vérifiez pas les dépendances dans la section require ou require-dev
whitelist de l'option: permettre aux dépendances spécifiques d'utiliser la version de développement
command : Exécutez une commande système
Option cmd la commande à exécuter
Option live_output booléen, affichons-nous la sortie de commande? (par défaut: true )
L'entier de timeout d'option, limite l'heure de la commande. (par défaut: 600 )
Option stop_on_error booléen, cassons-nous le processus de libération sur l'erreur? (par défaut: true )
Les actions peuvent être utilisées pour les pièces pré ou post-libération.
changelog-update : Mettez à jour un fichier ChangeLog. Cette action est en outre configurée pour utiliser un formateur spécifique.
format d'option: Simple , sémantique , Markdown ou AddTop (par défaut: simple )
file d'option: Chemin de .rmt.yml vers le fichier de changeLog (par défaut: ChangeLog )
Option dump-commits : écrivez tous les messages de validation depuis la dernière version dans le fichier ChangeLog (par défaut: false )
Option insert-at : UNIQUEMENT pour le formateur AddTop: Nombre de lignes à sauter en haut du fichier Changelog avant d'ajouter le numéro de version (par défaut: 0 )
Option exclude-merge-commits : exclure les engagements de fusion du changelog (par défaut: false )
vcs-commit : Commissez tous les fichiers de la copie de travail (utilisez-le uniquement avec la working-copy-check PRÉREQUIS)
Option commit-message : Spécifiez un message de validation personnalisé. % La version% sera remplacée par les chaînes de version actuelles / suivantes.
vcs-tag : Tag le dernier engagement
vcs-publish : Publier les modifications (commits et tags)
composer-update : Mettez à jour le numéro de version dans un fichier de compositeur (notez que lors de l'utilisation de packagist.org, il est recommandé de ne pas avoir de balise dans Composer.json car la version est gérée par des balises de contrôle de version)
files-update : Mettez à jour la version dans un ou plusieurs fichiers. Pour chaque fichier à mettre à jour, veuillez fournir un tableau avec
file d'option: chemin vers le fichier à mettre à jour
pattern d'option: facultatif, utilisez pour spécifier le modèle de remplacement de chaîne dans votre fichier. Par exemple: const VERSION = '%version%';
build-phar-package : construit un package phar du projet actuel dont le nom de fichier dépend de l'option «nom de package» et de la version déployée: [nom de package] - [version] .phar
package-name d'option: le nom du package Générer
Option destination : le répertoire de destination pour créer le package. S'il est préfixé avec une barre oblique, est considéré comme absolu, autrement par rapport à la racine du projet.
Option excluded-paths : un regex de chemins exclus, transmis directement à la méthode Phar :: BuildFromDirectory. Ex: /^(?!.*cookbooks|.*.vagrant|.*.idea).*$/im .vagrant|.*.idea).*$/im
metadata d'option: un tableau de métadonnées décrivant le package. Ex auteur, projet. Remarque: La version de version est ajoutée par défaut mais peut être remplacée ici.
Option default-stub-cli : Le stub par défaut pour l'utilisation CLI du package.
Option default-stub-web : le stub par défaut pour l'utilisation de l'application Web du package.
command : Exécutez une commande système
Option cmd la commande à exécuter
Option live_output booléen, affichons-nous la sortie de commande? (par défaut: true )
L'entier de timeout d'option, limite l'heure de la commande. (par défaut: 600 )
Option stop_on_error booléen, cassons-nous le processus de libération sur l'erreur? (par défaut: true )
update-version-class : mettez à jour la constante de version dans un fichier de classe. Déprécié, utilisez files-update à la place
class d'options: chemin vers la classe à mettre à jour, ou nom de classe entièrement qualifié de la classe contenant la version constante
pattern d'option: facultatif, utilisez pour spécifier le modèle de remplacement de chaîne dans votre classe de version. % La version% sera remplacée par les chaînes de version actuelles / suivantes. Par exemple, vous pouvez utiliser const VERSION = '%version%'; . Si vous ne spécifiez pas cette option, chaque occurrence de la chaîne de version dans le fichier sera remplacée.
RMT fournit certaines actions, générateurs et persistants existants. Si nécessaire, vous pouvez ajouter le vôtre en créant un script PHP dans votre projet et en le faisant référence dans la configuration via son chemin relatif:
version-generator: "bin/myOwnGenerator.php"
Exemple avec paramètres injectés:
version-persister: name: "bin/myOwnGenerator.php" parameter1: value1
Par exemple, vous pouvez consulter le script /bin/updateApplicationVersionCurrentVersion.php configuré ici.
AVERTISSEMENT: Comme le name de clé est utilisé pour définir le nom de l'objet, vous ne pouvez pas avoir un name nommé paramètre.
La plupart du temps, il vous sera plus facile de prendre un exemple ci-dessous et de l'adapter à vos besoins.
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 vous souhaitez vous aider, en soumettant l'un de vos scripts, générateurs ou persistants d'action. Ou simplement en signalant un bug, accédez à la page du projet https://github.com/liip/rmt.
Si vous fournissez un PR, essayez de l'associer à des tests unité ou fonctionnels. Voir la section suivante
Pour pouvoir exécuter les tests localement, vous avez besoin:
phpunit
git
mercuriel
Vous pouvez les installer tous avec Brew:
> brew install phpunit git hg
Les tests testent également la création du phar RMT. Vous devez donc l'autoriser dans votre php.ini, en décalmentant cette ligne:
phar.readonly = Off
Enfin, pour exécuter les tests, il suffit de lancer Phpunit
> phpunit
Les tests fonctionnels sont une configuration RMT temporaire entièrement fonctionnelle. Chaque fois que vous exécutez un test fonctionnel, il crée un dossier temporaire avec un projet RMT. Ensuite, la suite de tests exécute des commandes RMT dessus et vérifiez les résultats. C'est pourquoi vous devez installer Git et Mercurial.
Pour déboguer les tests fonctionnels RMT, le meilleur est d'entrer dans ce dossier temporaire et d'explorer manuellement le projet. Pour ce faire, ajoutez simplement un petit $this->manualDebug(); dans la suite de tests. Cela brisera le test avec la sortie suivante:
MANUAL DEBUG Go to: > cd /private/var/folders/hl/gnj5dcj55gbc93pcgrjxbb0w0000gn/T/ceN2Mf
Ensuite, il vous suffit d'aller dans le dossier mentionné et de commencer à déboguer
Jonathan Macheret, Liip SA
David Jeanmonod Liip SA
et d'autres contributeurs
RMT est autorisé sous la licence du MIT. Voir le fichier de licence pour plus de détails.
