RMT
1.0.0
RMTは、ソフトウェアの新しいバージョンをリリースするのに役立つ便利なツールです。使用するバージョンジェネレーターのタイプ（Semanticバージョン化など）、バージョン（たとえば、ChangelogファイルまたはVCSタグとして）を保存する場合、および実行前または後に実行する必要があるアクションのリストを定義できます。新しいバージョンのリリース。
プロジェクトでRMTを使用するには、Composerを使用して開発者依存関係としてインストールする必要があります。プロジェクトのルートディレクトリに移動して実行するだけです。
composer require --dev liip/rmt
次に、次のコマンドを実行してRMTを初期化する必要があります。
php vendor/liip/rmt/command.php init
このコマンドは、プロジェクトのルートフォルダーに.rmt.yml configファイルとRMT実行可能なスクリプトを作成します。次を実行して、RMTの使用を開始できます。
./RMT
そこに着いたら、あなたの最良の選択肢は、以下の構成例の1つを選択して、ニーズに合わせて適応させることです。
バージョン化ツールを使用している場合は、Composerファイル（ composer.jsonとcomposer.lock ）、RMT構成ファイル（ .rmt.yml ）、 RMT実行可能スクリプトの両方を追加することをお勧めします。 vendorディレクトリはcomposer install実行するときに入力されるため、無視する必要があります。
Global Composer.jsonにRMTを追加し、すべてのプロジェクトでグローバルに利用できるようにすることができます。そのため、次のコマンドを実行するだけです。
composer global require liip/rmt
$パスに~/.composer/vendor/bin/持っていることを確認してください。
RMTは、そのためにインストールする必要があるPhAR composerを介してインストールできます。この便利なツールを使用すると、Composerパッケージから実行可能なPhARファイルを作成できます。
PhAR composerがインストールされている場合は、実行できます。
sudo phar-composer install liip/RMT
PhAR-Composerをビルドして$パスにファイルファイルをインストールします。これにより、コマンドラインからrmtとして単純に実行できます。
phar-composer build liip/RMT
結果のファーファイルを必要な場所に手動でコピーします（ chmod +x rmt.pharを介してpharファイルを実行可能にして直接実行するか、 ./rmt.phar php rmt.pharを介してphpを介してそれを呼び出して実行します。
使用法を使用することを決定したバリアントを使用して、使用法の場合。
プロジェクトにhttps://github.com/liip/drifterを使用している場合は、3つのステップが必要です
rmtロールをアクティブにします
プロビジョニングのvagrant provisionを再実行します
あなたのプロジェクトのためのinit rmt php /home/vagrant/.config/composer/vendor/liip/rmt/RMT
RMTの使用は非常に簡単で、コマンドを実行するだけです。
./RMT release
RMTは次のタスクを実行します。
前提条件チェックを実行します
潜在的な質問に答えるようにユーザーに依頼します
プレリリースアクションを実行します
リリース
新しいバージョン番号を生成します
新しいバージョン番号を保持します
リリース後のアクションを実行します
これが出力の例です。
releaseコマンドはツールの主な動作を提供し、追加の追加コマンドを追加します。
currentあなたのプロジェクトの現在のバージョン番号（エイリアスバージョン）を表示します
changes次のリリースに組み込まれる変更を表示します
config現在の構成を表示します（既にマージされています）
.rmt.yml configファイルを作成（またはリセット） init
すべてのRMT構成は.rmt.ymlで実行する必要があります。ファイルは6つのルート要素で分割されています。
vcs ：使用しているVCのタイプ、 git 、 svn 、またはnoneにすることができます
git VCSの場合、GPGにリリースにsign-commitする場合は、次の2つのオプションを使用できますsign-tag
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という名前のルート要素に配置する必要があります。その後、ブランチmasterのこのデフォルト構成の一部をオーバーライドできます。例：
_default: version-generator: "simple" version-persister: "vcs-tag" master: pre-release-actions: [changelog-update]
コマンドRMT configを使用して、_Defaultと現在のブランチの間のマージ結果を確認できます。
ビルドインバージョン番号生成戦略。
シンプル：このジェネレーターは簡単な増分を行っています（1,2,3 ...）
セマンティック：セマンティックバージョンを実装するジェネレーター
2つの強制オプションは、特定のブランチが特定のバージョンの次のベータに専用であると判断した場合に非常に便利です。したがって、ラベルをベータ版に強制するだけで、すべてのリリースがベータ版の増分になります。
オプションallow-label （boolean）：バージョン（-beta、-rcxxなど）にラベルを追加できるようにするには）（デフォルト： false ）
オプションtype ：バージョンタイプを強制します
オプションlabel ：ラベルを強制する
バージョン番号の保存/取得を担当するクラス。
VCS-TAG：バージョンをVCSタグとして保存します
Option 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 ：VCSローカル変更がないことを確認してください
オプションallow-ignore ： --ignore-checkでリリースを行うときにユーザーがチェックをスキップできるようにします
display-last-changes ：最後の変更を表示します
tests-check ：プロジェクトテストスイートを実行します
オプションcommand ：実行するコマンド（デフォルト： phpunit ）
オプションtimeout ：コマンドがタイムアウトする秒数（デフォルト： 60.0 ）
オプションexpected_exit_code ：suggest return code（default： 0 ）
composer-json-check ：composer.jsonで検証を実行します
オプションcomposer ：作曲家の実行方法（デフォルト： php composer.phar ）
composer-stability-check ：Composer.jsonが適切な最小安定性に設定されているかどうかを確認します
オプションのstability ：最小安定性フィールドに設定する安定性（デフォルト：安定）
composer-security-check ：composer.lockをhttps://github.com/fabpot/local-php-security-checkerに対して実行して、依存関係の既知の脆弱性を確認します。
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ファイルからパス（デフォルト： changelog ）
オプションdump-commits ：最後のリリース以来、すべてのコミットメッセージをChangelogファイルに記述します（デフォルト： false ）
Option insert-at ：AddTop Formatterのみ：リリース番号を追加する前にChangelogファイルの上部からスキップする行の数（デフォルト： 0 ）
オプションexclude-merge-commits ：cangeLogからコミットを除外する（デフォルト： false ）
vcs-commit ：ワーキングコピーのすべてのファイルをコミットします（ working-copy-check前提条件でのみ使用）
オプションcommit-message ：カスタムコミットメッセージを指定します。 ％バージョン％は、現在 /次のバージョン文字列に置き換えられます。
vcs-tag ：最後のコミットにタグを付けます
vcs-publish ：変更を公開（コミットとタグ）
composer-update ：Composerファイルでバージョン番号を更新します（packagist.orgを使用する場合は、バージョンがバージョン制御タグによるハンドルであるため、composer.jsonにタグを持たないことをお勧めします）
files-update ：1つまたは複数のファイルでバージョンを更新します。各ファイルが更新するために、で配列を提供してください
オプションfile ：更新するファイルへのパス
オプションpattern ：オプション、ファイルの文字列置換パターンを指定するために使用します。例： const VERSION = '%version%';
build-phar-package ：ファイル名が「パッケージ名」オプションと展開バージョンに依存する現在のプロジェクトのファーパッケージを構築します：[パッケージ名] - [バージョン] .phar
オプションpackage-name ：生成パッケージの名前
オプションdestination ：パッケージを構築するための宛先ディレクトリ。スラッシュが付いている場合、プロジェクトルートに比べて絶対的であると見なされます。
オプションexcluded-paths ：除外されたパスの正規表現、Phar :: BuildFromDirectoryメソッドに直接渡されます。 ex： /^(?!.*cookbooks|.*.vagrant|.*.idea).*$/im .*.vagrant|.*.idea）.*$/im
オプションmetadata ：パッケージを説明するメタデータの配列。元著者、プロジェクト。注：リリースバージョンはデフォルトで追加されますが、ここでオーバーライドできます。
オプションdefault-stub-cli ：パッケージのCLI使用量のデフォルトのスタブ。
オプションdefault-stub-web ：パッケージの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/updateapplicationcurrentversion.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でインストールできます：
> brew install phpunit git hg
テストでは、RMTファーの作成もテストしています。したがって、この行を除外して、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
その後、上記のフォルダーに移動してデバッグを開始する必要があります
Jonathan Macheret、Liip SA
David Jeanmonod liip SA
その他の貢献者
RMTはMITライセンスの下でライセンスされています。詳細については、ライセンスファイルを参照してください。
