RMT
1.0.0
RMT ist ein praktisches Tool, mit dem neue Versionen Ihrer Software veröffentlicht werden können. Sie können den Typ des Versionsgenerators definieren, den Sie verwenden möchten (z. B. semantische Versioning) Veröffentlichung einer neuen Version.
Um RMT in Ihrem Projekt zu verwenden, sollten Sie einen Komponisten verwenden, um es als Dev-Abhängigkeit zu installieren. Gehen Sie einfach zum Root Directory Ihres Projekts und führen Sie aus:
composer require --dev liip/rmt
Dann müssen Sie RMT initialisieren, indem Sie den folgenden Befehl ausführen:
php vendor/liip/rmt/command.php init
Dieser Befehl erstellt eine .rmt.yml -Konfigurationsdatei und ein RMT -ausführbares Skript im Stammordner Ihres Projekts. Sie können jetzt RMT verwenden, indem Sie ausführen:
./RMT
Nachdem Sie dort eine der folgenden Konfigurationsbeispiele auswählen und an Ihre Anforderungen anpassen können.
Wenn Sie ein Versions -Tool verwenden, empfehlen wir, beide Composer -Dateien ( composer.json und composer.lock ), die RMT -Konfigurationsdatei ( .rmt.yml ) und das ausführbare RMT -Skript hinzuzufügen. Das vendor sollte ignoriert werden, da es beim Ausführen composer install installiert ist.
Sie können RMT zu Ihrem globalen Composer.json hinzufügen und es weltweit für alle Ihre Projekte zur Verfügung stellen. Daher führen Sie einfach den folgenden Befehl aus:
composer global require liip/rmt
Stellen Sie sicher, dass Sie ~/.composer/vendor/bin/ in Ihrem $ path haben.
RMT kann über den Phar-Komponisten installiert werden, der dafür installiert werden muss. Mit diesem nützlichen Tool können Sie runnable Phar -Dateien aus Composer -Paketen erstellen.
Wenn Sie den Phar-Komponisten installiert haben, können Sie ausführen:
sudo phar-composer install liip/RMT
Lassen Sie den Phar-Komponisten die PHAR-Datei auf Ihrem $ -Path erstellen und installieren, sodass Sie sie einfach als rmt aus der Befehlszeile ausführen können oder Sie ausführen können
phar-composer build liip/RMT
und kopieren Sie die resultierende PHAR -Datei manuell an die Stelle, an der Sie sie benötigen (entweder erstellen Sie die PHAR -Datei über chmod +x rmt.phar php rmt.phar und führen Sie sie direkt aus ./rmt.phar
Für den Verwendungssatz RMT mit jeder Variante, für die Sie sich entschieden haben.
Wenn Sie https://github.com/liip/drifter für Ihr Projekt verwenden, benötigen Sie nur drei Schritte
Aktivieren Sie die rmt -Rolle
Die vorgesehene vagrant provision neu ausführen
Init rmt für Ihr Projekt php /home/vagrant/.config/composer/vendor/liip/rmt/RMT
Die Verwendung von RMT ist sehr einfach, führen Sie einfach den Befehl aus:
./RMT release
RMT wird dann die folgenden Aufgaben ausführen:
Führen Sie die Voraussetzungen durch
Bitten Sie den Benutzer, potenzielle Fragen zu beantworten
Führen Sie die Aktionen vor der Veröffentlichung aus
Freigeben
Generieren Sie eine neue Versionsnummer
Behalten Sie die neue Versionsnummer an
Führen Sie die Aktionen nach der Veröffentlichung aus
Hier ist ein Beispielausgang:
Der Befehl release bietet das Hauptverhalten des Tools. Weitere zusätzliche Befehle sind verfügbar:
current zeigt Ihre Projekt aktuelle Versionsnummer an (Alias -Version)
changes Zeigen Sie die Änderungen an, die in der nächsten Version aufgenommen werden
config Zeigen Sie die aktuelle Konfiguration an (bereits zusammengeführt)
init erstellen (oder reset) die Konfigurationsdatei .rmt.yml
Alle RMT -Konfigurationen müssen in .rmt.yml durchgeführt werden. Die Datei ist in sechs Stammelementen unterteilt:
vcs : Die Art der VCs, die Sie verwenden, kann git , svn oder none sein
Für git VCS können Sie die beiden folgenden Optionen sign-commit sign-tag
prerequisites : Eine Liste [] der Voraussetzungen, die vor Beginn des Veröffentlichungsprozesses übereinstimmen müssen
pre-release-actions : Eine Liste [] von Aktionen, die vor dem Freigabeprozess ausgeführt werden
version-generator : Der Generator, mit dem eine neue Version erstellt wird (obligatorisch)
version-persister : Die Persister, um die Versionen zu speichern (obligatorisch)
post-release-actions : Eine Liste [] von Aktionen, die nach der Veröffentlichung ausgeführt werden
Alle Einträge dieser Konfiguration funktionieren gleich. Sie müssen die Klasse angeben, die Sie mit der Aktion umgehen möchten. Beispiel:
version-generator: "simple"` version-persister: vcs-tag: tag-prefix: "v_"
RMT unterstützt auch JSON -Konfigurationen, empfehlen jedoch, YAML zu verwenden.
Manchmal möchten Sie eine andere Release -Strategie gemäß der VCS -Filiale anwenden, z. B. Sie möchten ChangeLog -Einträge nur im master -Zweig hinzufügen. Dazu müssen Sie Ihre Standardkonfiguration in ein Root -Element mit dem Namen _default einsetzen, und dann können Sie Teile dieser Standardkonfiguration für den Zweig master überschreiben. Beispiel:
_default: version-generator: "simple" version-persister: "vcs-tag" master: pre-release-actions: [changelog-update]
Sie können die Befehls RMT config verwenden, um das Merge -Ergebnis zwischen _Default und Ihrem aktuellen Zweig anzuzeigen.
Build-In-Versionsnummer-Generierungsstrategien.
Einfach: Dieser Generator macht ein einfaches Inkrement (1,2,3 ...)
Semantik: Ein Generator, der semantische Versioning implementiert
Die beiden erzwungenen Option könnte sehr nützlich sein, wenn Sie entscheiden, dass eine bestimmte Zweigstelle der nächsten Beta einer bestimmten Version gewidmet ist. Erzwingen Sie also einfach das Etikett zur Beta und alle Veröffentlichungen werden Beta -Inkremente sein.
Option allow-label (boolean): Ermöglicht das Hinzufügen eines Etiketts in einer Version (z. B. -beta, -rcxx) (Standard: Falsch )
type : So erzwingen Sie den Versionstyp
label : Um das Etikett zu erzwingen
Klasse, die für das Speichern/Abrufen der Versionsnummer verantwortlich ist.
VCS-Tag: Speichern Sie die Version als VCS-Tag
Options tag-pattern : Ermöglichen Sie, einen Regex anzugeben, den alle Tags übereinstimmen müssen. Dadurch können Sie beispielsweise eine Version 1.xx in einer bestimmten Filiale veröffentlichen und einen 2.xx in einer separaten Filiale freigeben
Option tag-prefix : Ermöglichen Sie das Präfix aller VCS-Tags mit einer Zeichenfolge. Sie können eine numerische Versions haben, aber Generierungs -Tags wie v_2.3.4 . Als Bonus können Sie einen bestimmten Platzhalter verwenden: {branch-name} der den aktuellen Zweignamen automatisch in das Tag injiziert. Verwenden Sie also eine einfache Generation und tag-prefix: "{branch-name}_" und generiert Tag wie featureXY_1 , featureXY_2 usw.
ChangeLog: Speichern Sie die Version in der ChangeLog -Datei
Option location : Changelog -Datein Name Ein Speicherort (Standard: ChangeLog )
Voraussetzungen werden vor dem interaktiven Teil ausgeführt.
working-copy-check : Überprüfen Sie, ob Sie keine lokalen VCS-Änderungen haben
Option allow-ignore : Ermöglichen Sie dem Benutzer, die Überprüfung der Überprüfung bei einer Version mit --ignore-check zu überspringen
display-last-changes : Zeigen Sie Ihre letzten Änderungen an
tests-check : Führen Sie die Projekttestsuite aus
command Option: Befehl zum Ausführen (Standard: phpunit )
Option timeout : Die Anzahl der Sekunden danach ist der Befehl aus (Standardeinstellung: 60.0 )
Option expected_exit_code : erwarteter Rückgabecode (Standard: 0 )
composer-json-check : Führen Sie einen Validieren auf dem Composer.json aus
composer : So führen Sie den Komponisten aus (Standard: Php Composer.phar )
composer-stability-check : Überprüft, ob der Composer.json auf die richtige Mindeststabilität eingestellt ist
stability : Die Stabilität, die im Feld Minimum-Stabilität festgelegt werden sollte (Standard: Stabil )
composer-security-check : Führen Sie den Composer.lock gegen https://github.com/fabpot/local-php-security-checker aus, um nach bekannten Schwachstellen in den Abhängigkeiten zu überprüfen.
Die lokale Binärdatei-Prüfungs-Prüfungs-Binärdatei muss weltweit installiert werden.
composer-dependency-stability-check : Test Wenn nur zugelassene Abhängigkeiten Entwicklungsversionen verwenden
Option ignore-require und ignore-require-dev : Überprüfen Sie die Abhängigkeiten nicht im Abschnitt require require-dev
Option whitelist : Ermöglichen Sie spezifische Abhängigkeiten, die Entwicklungsversion zu verwenden
command : Führen Sie einen Systembefehl aus
Option cmd Der ausführende Befehl
Option live_output Boolean, anzeigen wir die Befehlsausgabe an? (Standard: wahr )
Option timeout Integer, begrenzt die Zeit für den Befehl. (Standard: 600 )
Option stop_on_error boolean, brechen wir den Release -Prozess auf Fehler auf? (Standard: wahr )
Aktionen können für Teile vor oder nach der Veröffentlichung verwendet werden.
changelog-update : Aktualisieren Sie eine Changelog-Datei. Diese Aktion ist weiter so konfiguriert, dass sie einen bestimmten Formatierer verwenden.
format : Einfach , semantisch , Markdown oder Addtop (Standard: Einfach )
file : Pfad von .rmt.yml zu ChangeLog -Datei (Standard: ChangeLog )
Option dump-commits : Schreiben Sie alle Festschreibungsnachrichten seit der letzten Version in die ChangeLog-Datei (Standard: Falsch )
Option insert-at : Nur für Addtop-Formatierer: Anzahl der Zeilen, die oben in der ChangeLog-Datei überspringen können, bevor Sie die Freigabennummer hinzufügen (Standard: 0 )
Option exclude-merge-commits : Merge-Commits aus dem Changelog ausschließen (Standard: Falsch )
vcs-commit : Begründen Sie alle Dateien der Arbeitskopie (verwenden Sie sie nur mit der Voraussetzung für die working-copy-check )
Option commit-message : Geben Sie eine benutzerdefinierte Commit-Nachricht an. % Version% wird durch die aktuellen / nächsten Versionszeichenfolgen ersetzt.
vcs-tag : Tag das letzte Commit
vcs-publish : Veröffentlichen Sie die Änderungen (Commits und Tags)
composer-update : Aktualisieren Sie die Versionsnummer in einer Composer-Datei (Beachten Sie, dass bei Verwendung von packagist.org kein Tag in Composer.json, da die Version von Versionssteuer-Tags verarbeitet wird.
files-update : Aktualisieren Sie die Version in einem oder mehreren Dateien. Damit jede Datei aktualisiert werden kann, geben Sie bitte ein Array mit
file : Pfad zur Aktualisierung der Datei
pattern : Optional, verwenden Sie das Zeichen -Ersatzmuster in Ihrer Datei. Zum Beispiel: const VERSION = '%version%';
build-phar-package : Erstellt ein Phar-Paket des aktuellen Projekts, dessen Dateiname von der Option "Paketname" und der bereitgestellten Version abhängt: [Paketname]-[Version] .Phar
package-name : Der Name des Pakets generieren
destination : Das Zielverzeichnis zum Erstellen des Pakets in. Wenn er mit einem Schrägstrich vorangestellt wird, gilt sie als absolut, ansonsten relativ zur Projektwurzel.
Option excluded-paths : Eine Regex von ausgeschlossenen Pfaden, direkt an die Phar :: BuildFromDirectory-Methode übergeben. Ex: /^(?!.*cookbooks|.*.vagrant|.*.idea).*$/im
Option metadata : Eine Reihe von Metadaten, die das Paket beschreiben. Ex -Autor, Projekt. Hinweis: Die Versionsversion wird standardmäßig hinzugefügt, kann jedoch hier überschrieben werden.
Option default-stub-cli : Der Standardstub für die CLI-Verwendung des Pakets.
Option default-stub-web : Der Standardstub für die Nutzung des Pakets für Webanwendungen.
command : Führen Sie einen Systembefehl aus
Option cmd Der ausführende Befehl
Option live_output Boolean, anzeigen wir die Befehlsausgabe an? (Standard: wahr )
Option timeout Integer, begrenzt die Zeit für den Befehl. (Standard: 600 )
Option stop_on_error boolean, brechen wir den Release -Prozess auf Fehler auf? (Standard: wahr )
update-version-class : Aktualisieren Sie die Versionskonstante in einer Klassendatei. Veraltet, verwenden Sie stattdessen files-update
class : Pfad zur aktualisierten Klasse oder vollständig qualifizierter Klassenname der Klasse, die die Versionskonstante enthält
pattern : Optional, verwenden Sie das String -Ersatzmuster in Ihrer Versionsklasse. % Version% wird durch die aktuellen / nächsten Versionszeichenfolgen ersetzt. Zum Beispiel könnten Sie const VERSION = '%version%'; . Wenn Sie diese Option nicht angeben, wird jedes Vorkommen der Versionszeichenfolge in der Datei ersetzt.
RMT liefert einige vorhandene Aktionen, Generatoren und Persistenten. Bei Bedarf können Sie Ihr eigenes hinzufügen, indem Sie ein PHP -Skript in Ihrem Projekt erstellen und es in der Konfiguration über den relativen Pfad verweisen:
version-generator: "bin/myOwnGenerator.php"
Beispiel mit injizierten Parametern:
version-persister: name: "bin/myOwnGenerator.php" parameter1: value1
Beispielsweise können Sie sich das hier konfigurierte Skript /bin/UpDateApplicationVersionCurrentversion.php ansehen.
WARNUNG: Da der name verwendet wird, um den Namen des Objekts zu definieren, können Sie keinen Parameter namens name haben.
In den meisten Fällen ist es für Sie leichter, ein Beispiel unten aufzunehmen und es an Ihre Bedürfnisse anzupassen.
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-tagWenn Sie helfen möchten, indem Sie eines Ihrer Aktionskripte, Generatoren oder Persistenten einreichen. Oder nur durch Berichterstattung über einen Fehler gehen Sie einfach zur Projektseite https://github.com/liip/rmt.
Wenn Sie eine PR angeben, versuchen Sie, es einige Einheiten oder Funktionstests zuzuordnen. Siehe Nächster Abschnitt
Um die Tests lokal ausführen zu können, benötigen Sie:
Phpunit
Git
Quecksilber
Sie können alle mit Brauen installieren:
> brew install phpunit git hg
Die Tests testen auch die Erstellung des RMT -Phar. Sie müssen dies also in Ihrem Php.ini zulassen, indem Sie diese Linie überzeugen:
phar.readonly = Off
Um die Tests durchzuführen, starten Sie einfach Phpunit
> phpunit
Die Funktionstests sind voll funktionaler temporärer RMT -Setup. Jedes Mal, wenn Sie den Funktionstest ausführen, wird ein temporärer Ordner mit einem RMT -Projekt erstellt. Anschließend werden RMT -Befehle darauf ausgeführt und überprüft die Ergebnisse. Deshalb müssen Sie Git und Mercurial installieren lassen.
Um RMT -Funktionstests zu debuggen, ist es am besten, in diesen temporären Ordner zu gehen und das Projekt manuell zu untersuchen. Fügen Sie dazu einfach ein kleines $this->manualDebug(); in die Testsuite. Dies wird den Test mit der folgenden Ausgabe durchbrechen:
MANUAL DEBUG Go to: > cd /private/var/folders/hl/gnj5dcj55gbc93pcgrjxbb0w0000gn/T/ceN2Mf
Dann müssen Sie nur in den erwähnten Ordner gehen und mit dem Debuggen beginnen
Jonathan Macheret, Liip SA
David Jeanmonod liip sa
und andere Mitwirkende
RMT ist unter der MIT -Lizenz lizenziert. Weitere Informationen finden Sie in der Lizenzdatei.
