RMT
1.0.0
O RMT é uma ferramenta útil para ajudar a lançar novas versões do seu software. Você pode definir o tipo de gerador de versão que deseja usar (por exemplo, versão semântica), onde deseja armazenar a versão (por exemplo, em um arquivo de changelog ou como uma tag VCS) e uma lista de ações que devem ser executadas antes ou depois da liberação de uma nova versão.
Para usar o RMT no seu projeto, você deve usar o Composer para instalá-lo como dependência do dev. Basta ir ao diretório raiz do seu projeto e executar:
composer require --dev liip/rmt
Então você deve inicializar o RMT executando o seguinte comando:
php vendor/liip/rmt/command.php init
Este comando criará um arquivo de configuração .rmt.yml e um script executável RMT na pasta raiz do seu projeto. Agora você pode começar a usar o RMT executando:
./RMT
Uma vez lá, sua melhor opção é escolher um dos exemplos de configuração abaixo e adaptá -lo às suas necessidades.
Se você estiver usando uma ferramenta de versão, recomendamos adicionar arquivos de compositores ( composer.json e composer.lock ), o arquivo de configuração RMT ( .rmt.yml ) e o script executável RMT . O diretório vendor deve ser ignorado, pois é preenchido ao executar composer install .
Você pode adicionar RMT ao seu Composer.json global e disponibilizá -lo globalmente para todos os seus projetos. Para executar o seguinte comando:
composer global require liip/rmt
Certifique -se de ter ~/.composer/vendor/bin/ no seu caminho $.
O RMT pode ser instalado através do Phar-Composer, que precisa ser instalado para isso. Esta ferramenta útil permite criar arquivos PHAR executáveis a partir de pacotes de compositores.
Se você tem o Phar-Composer instalado, poderá executar:
sudo phar-composer install liip/RMT
e peça a Phar-Composer construir e instalar o arquivo PHAR no seu $ PATH, que permite que você o execute simplesmente como rmt da linha de comando ou você pode executar
phar-composer build liip/RMT
e copie o arquivo PHAR resultante manualmente para onde você precisa (faça o arquivo PHAR executável via chmod +x rmt.phar e execute -o diretamente ./rmt.phar ou executando -o invocando -o através do PHP via php rmt.phar .
Para o uso, substitua o RMT por qualquer variante que você tenha decidido usar.
Se você estiver usando https://github.com/liip/drifter para o seu projeto, você só precisa de três etapas
Ative o papel rmt
Re-executar a vagrant provision provisório
Init rmt para o seu projeto php /home/vagrant/.config/composer/vendor/liip/rmt/RMT
Usar o RMT é muito direto, basta executar o comando:
./RMT release
O RMT executará as seguintes tarefas:
Executar os cheques de pré -requisitos
Peça ao usuário para responder a perguntas em potencial
Executar as ações de pré-lançamento
Liberar
Gerar um novo número de versão
Persiste o novo número da versão
Executar as ações pós-liberação
Aqui está um exemplo de saída:
O comando release fornece o principal comportamento da ferramenta, alguns comandos adicionais estão disponíveis:
current mostrará o número da versão atual do seu projeto (versão do alias)
changes exibem as alterações que serão incorporadas na próxima versão
config Exibir a configuração atual (já mesclada)
init crie (ou redefinir) o arquivo de configuração .rmt.yml
Todas as configurações RMT devem ser feitas em .rmt.yml . O arquivo é dividido em seis elementos raiz:
vcs : o tipo de VCS que você está usando, pode ser git , svn ou none
Para os VCs git , você pode usar as duas opções seguintes e sign-commit sign-tag você quiser assinar sua versão
prerequisites : uma lista [] de pré -requisitos que devem ser correspondidos antes de iniciar o processo de liberação
pre-release-actions : uma lista [] de ações que serão executadas antes do processo de liberação
version-generator : o gerador a ser usado para criar uma nova versão (obrigatória)
version-persister : o Persister a usar para armazenar as versões (obrigatório)
post-release-actions : uma lista [] de ações que serão executadas após a liberação
Todas as entradas desta configuração funcionam da mesma forma. Você precisa especificar a classe que deseja lidar com a ação. Exemplo:
version-generator: "simple"` version-persister: vcs-tag: tag-prefix: "v_"
O RMT também suporta configurações JSON, mas recomendamos o uso da YAML.
Às vezes, você deseja usar uma estratégia de liberação diferente de acordo com a filial do VCS, por exemplo, você deseja adicionar entradas de Changelog apenas na filial master . Para fazer isso, você deve colocar sua configuração padrão em um elemento raiz chamado _default , então você pode substituir partes desta configuração padrão para o master da filial. Exemplo:
_default: version-generator: "simple" version-persister: "vcs-tag" master: pre-release-actions: [changelog-update]
Você pode usar o comando RMT config para ver o resultado da mesclagem entre _default e sua ramificação atual.
Estratégias de geração de números de versão de construção.
Simples: este gerador está fazendo um incremento simples (1,2,3 ...)
Semântico: um gerador que implementa a versão semântica
A opção forçada pode ser muito útil se você decidir que uma determinada filial é dedicada ao próximo beta de uma determinada versão. Portanto, basta forçar o rótulo para a beta e toda a liberação serão incrementos beta.
Opção allow-label (booleano): para permitir a adição de um rótulo em uma versão (como -beta, -rcxx) (padrão: false )
type de opção: para forçar o tipo de versão
label da opção: para forçar o rótulo
Classe responsável por salvar/recuperar o número da versão.
VCs-TAG: salve a versão como uma tag VCS
Opção tag-pattern : Deixe fornecer um regex que toda a tag deve corresponder. Isso permite que, por exemplo
Opção tag-prefix : permita prefixar todas as tags VCs com uma string. Você pode ter um versão numérica, mas tags de geração como v_2.3.4 . Como bônus, você pode usar um espaço reservado específico: {branch-name} que injetará automaticamente o nome atual da ramificação na tag. Portanto, use, geração simples e tag-prefix: "{branch-name}_" e gerará tags como featureXY_1 , featureXY_2 , etc ...
Changelog: salve a versão no arquivo Changelog
Opção location : Changelog Nome de um local (padrão: Changelog )
Ações de pré -requisito são executadas antes da parte interativa.
working-copy-check : verifique se você não tem nenhuma alteração local do VCS
Opção allow-ignore : Deixe o usuário pular a verificação ao fazer um lançamento com --ignore-check
display-last-changes : exiba suas últimas alterações
tests-check : Execute o Project Test Suite
command de opção: comando para executar (padrão: phpunit )
timeout da opção: o número de segundos após o qual o comando se destaca (padrão: 60.0 )
Opção expected_exit_code : Código de retorno esperado (Padrão: 0 )
composer-json-check : execute um validate no composer.json
Opção composer : Como executar o Composer (Padrão: Php Composer.phar )
composer-stability-check : verificará se o composer.json está definido para a estabilidade mínima certa
stability da opção: a estabilidade que deve ser definida no campo de estabilidade mínima (padrão: estável )
composer-security-check : execute o composer.lock contra https://github.com/fabpot/local-php-security-checker para verificar as vulnerabilidades conhecidas nas dependências.
O binário local-php-security-checker deve ser instalado globalmente.
composer-dependency-stability-check : teste se apenas as dependências permitirem usar versões de desenvolvimento
Opção ignore-require e ignore-require-dev : não verifique as dependências na seção require ou require-dev
Option whitelist : Permitir dependências específicas use a versão de desenvolvimento
command : execute um comando do sistema
Opção cmd o comando para executar
Opção live_output Boolean, exibimos a saída de comando? (Padrão: true )
timeout da opção Inteiro, limita o tempo para o comando. (Padrão: 600 )
Opção stop_on_error boolean, quebramos o processo de liberação em erro? (Padrão: true )
As ações podem ser usadas para peças pré ou pós -liberação.
changelog-update : Atualize um arquivo Changelog. Esta ação é configurada ainda mais para usar um formatador específico.
format de opção: simples , semântico , marecha ou addTop (padrão: simples )
file de opção: Path de .rmt.yml to Changelog File (padrão: Changelog )
Opção dump-commits : Escreva todas as mensagens de comprometimento desde a última versão no arquivo Changelog (padrão: false )
Opção insert-at : somente para addtop formatador: número de linhas para pular da parte superior do arquivo Changelog antes de adicionar o número da liberação (padrão: 0 )
Opção exclude-merge-commits : exclude Merge Commits do Changelog (Padrão: False )
vcs-commit : Comprometa todos os arquivos da cópia de trabalho (use-o apenas com o pré-requisito working-copy-check )
Opção commit-message : especifique uma mensagem de confirmação personalizada. % Versão% será substituída pelas seqüências de strings de versão atual / próxima.
vcs-tag : Tag o último compromisso
vcs-publish : Publique as alterações (cometidos e tags)
composer-update : Atualize o número da versão em um arquivo compositor (observe que, ao usar o packagist.org, é recomendável não ter uma tag em composer.json como a versão é identificada por tags de controle de versão)
files-update : Atualize a versão em um ou vários arquivos. Para cada arquivo a ser atualizado, forneça uma matriz com
file de opção: caminho para o arquivo para atualizar
pattern de opção: Opcional, use para especificar o padrão de substituição da string em seu arquivo. Por exemplo: const VERSION = '%version%';
build-phar-package : Construa um pacote PHAR do projeto atual cujo nome de arquivo depende da opção 'Nome do pacote' e da versão implantada: [pacote-name]-[versão] .phar
package-name de opções: o nome do pacote de geração
destination de opção: o diretório de destino para construir o pacote. Se prefixado com uma barra, é considerado absoluto, caso contrário, em relação à raiz do projeto.
Opção excluded-paths : um regex de caminhos excluídos, passada diretamente para o método Phar :: BuildFromDirectory. Ex: /^(?!.*cookbooks|.*.vagrant|.*.idea).*$/im
metadata da opção: uma variedade de metadados descrevendo o pacote. Ex autor, projeto. Nota: A versão de liberação é adicionada por padrão, mas pode ser substituída aqui.
Opção default-stub-cli : o stub padrão para o uso da CLI do pacote.
Opção default-stub-web : o stub padrão para o uso de aplicativos da web do pacote.
command : execute um comando do sistema
Opção cmd o comando para executar
Opção live_output Boolean, exibimos a saída de comando? (Padrão: true )
timeout da opção Inteiro, limita o tempo para o comando. (Padrão: 600 )
Opção stop_on_error boolean, quebramos o processo de liberação em erro? (Padrão: true )
update-version-class : Atualize a versão constante em um arquivo de classe. Descontinuado, use files-update em vez disso
class de opção: caminho para a classe a ser atualizado ou nome totalmente qualificado da classe que contém a versão constante
pattern de opção: Opcional, use para especificar o padrão de substituição da string na sua classe de versão. % Versão% será substituída pelas seqüências de strings de versão atual / próxima. Por exemplo, você pode usar const VERSION = '%version%'; . Se você não especificar esta opção, todas as ocorrências da string de versão no arquivo serão substituídas.
A RMT está fornecendo algumas ações, geradores e persistentes existentes. Se necessário, você pode adicionar o seu próprio criando um script PHP em seu projeto e referenciando -o na configuração por meio de seu caminho relativo:
version-generator: "bin/myOwnGenerator.php"
Exemplo com parâmetros injetados:
version-persister: name: "bin/myOwnGenerator.php" parameter1: value1
Como exemplo, você pode olhar para o script /bin/updateApplicationversionCurrentversion.php configurado aqui.
AVISO: Como o name da chave é usado para definir o nome do objeto, você não pode ter um parâmetro nomeado name .
Na maioria das vezes, será mais fácil para você pegar um exemplo abaixo e adaptá -lo às suas necessidades.
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-tagSe você quiser ajudar, enviando um de seus scripts de ação, geradores ou persistentes. Ou apenas relatando um bug, basta acessar a página do projeto https://github.com/liip/rmt.
Se você fornecer um PR, tente associá -lo a algumas unidades ou testes funcionais. Veja a próxima seção
Para poder executar os testes localmente, você precisa:
phpunit
git
mercurial
Você pode instalar todos eles com Brew:
> brew install phpunit git hg
Os testes também estão testando a criação do RMT Phar. Então você deve permitir isso em seu php.ini, descomentando esta linha:
phar.readonly = Off
Finalmente, para executar os testes, basta lançar a phpunit
> phpunit
Os testes funcionais são uma configuração RMT temporária totalmente funcional. Cada vez que você executa o teste funcional, ele cria uma pasta temporária com um projeto RMT. Em seguida, o conjunto de testes está executando comandos RMT e verifique os resultados. É por isso que você precisa ter o Git e o Mercurial instalado.
Para depurar testes funcionais da RMT, o melhor é entrar nesta pasta temporária e explorar manualmente o projeto. Para fazer isso, basta adicionar um pequeno $this->manualDebug(); na suíte de teste. Isso quebrará o teste com a seguinte saída:
MANUAL DEBUG Go to: > cd /private/var/folders/hl/gnj5dcj55gbc93pcgrjxbb0w0000gn/T/ceN2Mf
Então você só precisa entrar na pasta mencionada e começar a depurar
Jonathan Macheret, Liip SA
David Jeanmonod Liip SA
e outros colaboradores
O RMT está licenciado sob a licença do MIT. Consulte o arquivo de licença para obter detalhes.
