Release Please automatiza a geração de CHANGELOG, a criação de versões do GitHub e versões de versões para seus projetos.
Isso é feito analisando seu histórico do git, procurando mensagens de commit convencional e criando PRs de lançamento.
Ele não lida com a publicação em gerenciadores de pacotes nem com o gerenciamento complexo de filiais.
Em vez de liberar continuamente o que chega ao seu branch padrão, o release-please mantém os PRs de lançamento:
Esses PRs de lançamento são mantidos atualizados à medida que trabalhos adicionais são mesclados. Quando estiver pronto para marcar um lançamento, basta mesclar o PR do lançamento. Os commits squash-merge e merge funcionam com Release PRs.
Quando o Release PR é mesclado, o release executa as seguintes etapas:
Atualiza seu arquivo changelog (por exemplo CHANGELOG.md
), juntamente com outros arquivos específicos do idioma (por exemplo package.json
).
Marca o commit com o número da versão
Cria uma versão do GitHub com base na tag
Você pode saber onde o Release PR está em seu ciclo de vida pelo rótulo de status no próprio PR:
autorelease: pending
é o estado inicial do Release PR antes de ser mesclado
autorelease: tagged
significa que o Release PR foi mesclado e o lançamento foi marcado no GitHub
autorelease: snapshot
é um estado especial para alterações na versão do snapshot
autorelease: published
significa que uma versão do GitHub foi publicada com base no Release PR ( release-please não adiciona automaticamente esta tag, mas a recomendamos como uma convenção para ferramentas de publicação ).
Release Please assume que você está usando mensagens de commit convencionais.
Os prefixos mais importantes que você deve ter em mente são:
fix:
que representa correções de bugs e se correlaciona com um patch SemVer.
feat:
que representa um novo recurso e se correlaciona com um SemVer menor.
feat!:
, ou fix!:
, refactor!:
, etc., que representam uma alteração significativa (indicada pelo !
) e resultará em um SemVer major.
É altamente recomendável usar squash-merges ao mesclar solicitações pull. Um histórico linear do git torna muito mais fácil:
Seguir histórico - os commits são classificados por data de mesclagem e não são misturados entre solicitações pull
Encontre e reverta bugs - git bisect
é útil para rastrear qual alteração introduziu um bug
Controle o changelog release-please - ao mesclar um PR, você pode ter mensagens de commit que fazem sentido dentro do escopo do PR, mas não fazem sentido quando mescladas no branch principal. Por exemplo, você pode ter feat: introduce feature A
e então fix: some bugfix introduced in the first commit
. O commit fix
é, na verdade, irrelevante para as notas de lançamento, pois nunca houve um bug no branch principal.
Mantenha um branch principal limpo - se você usar algo como desenvolvimento vermelho/verde (crie um teste com falha no commit A e depois corrija no commit B) e faça merge (ou rebase-merge), então haverá pontos no tempo em seu branch principal onde os testes não passam.
Release Please permite representar múltiplas alterações em um único commit, usando rodapés:
façanha: adiciona UUID v4 à criptografia Isso adiciona suporte para UUIDs v4 à biblioteca. fix(utils): unicode não lança mais exceção PiperOrigin-RevId: 345559154 BREAKING-CHANGE: o método encode não é mais lançado. Link da fonte: googleapis/googleapis@5e0dcb2 feat(utils): atualiza a codificação para suportar unicode PiperOrigin-RevId: 345559182 Link da fonte: googleapis/googleapis@e5eef86
A mensagem de commit acima conterá:
uma entrada para o recurso "adiciona UUID v4 à criptografia" .
uma entrada para a correção "unicode não lança mais exceção" , junto com uma observação de que é uma alteração significativa.
uma entrada para o recurso "atualizar codificação para suportar unicode" .
Quando um commit para o branch principal tem Release-As: xxx
(sem distinção entre maiúsculas e minúsculas) no corpo do commit , Release Please abrirá uma nova solicitação pull para a versão especificada.
Exemplo de commit vazio:
git commit --allow-empty -m "chore: release 2.0.0" -m "Release-As: 2.0.0"
resulta na seguinte mensagem de commit:
tarefa: versão 2.0.0 Versão como: 2.0.0
Se você fundiu uma solicitação pull e gostaria de alterar a mensagem de commit usada para gerar as notas de versão para esse commit, você pode editar o corpo das solicitações pull mescladas e adicionar uma seção como:
BEGIN_COMMIT_OVERRIDE feat: add ability to override merged commit message fix: another message chore: a third message END_COMMIT_OVERRIDE
Na próxima vez que Release Please for executado, ele usará essa seção de substituição como a mensagem de commit em vez da mensagem de commit mesclada.
Release Please cria uma solicitação pull de release depois de perceber que o branch padrão contém "unidades liberáveis" desde o último lançamento. Uma unidade liberável é um commit para o branch com um dos seguintes prefixos: "feat", "fix" e "deps". (Um commit "chore" ou "build" não é uma unidade liberável.)
Algumas linguagens têm sua configuração de unidade liberável específica. Por exemplo, "docs" é um prefixo para unidades liberáveis em Java e Python.
autorelease: pending
ou autorelease: triggered
em um PR antigo Verifique as solicitações pull existentes rotuladas com autorelease: pending
ou autorelease: triggered
. Devido a falhas na API do GitHub, é possível que a tag não tenha sido removida corretamente em uma versão anterior e o Release Please pense que a versão anterior ainda está pendente. Se você tiver certeza de que não há liberação pendente, remova o rótulo autorelease: pending
ou autorelease: triggered
.
Para os usuários do aplicativo GitHub, Release Please não criará uma nova solicitação pull se houver uma solicitação pull existente rotulada como autorelease: pending
. Para confirmar este caso, procure uma solicitação pull com o rótulo. (É muito provável que seja a solicitação pull de lançamento mais recente.) Se você encontrar uma solicitação pull de lançamento com o rótulo e ela não for lançada (ou já lançada), remova o rótulo autorelease: pending
e execute novamente Release Please.
Se você acha que Release Please perdeu a criação de um PR de lançamento depois que uma solicitação pull com uma unidade liberável foi mesclada, execute novamente release-please
. Se você estiver usando o aplicativo GitHub, adicione o rótulo release-please:force-run
à solicitação pull mesclada. Se você estiver usando a ação, procure a invocação com falha e tente executar novamente o fluxo de trabalho. Release Please processará a solicitação pull imediatamente para encontrar unidades liberáveis.
Release Please automatiza lançamentos para os seguintes tipos de repositórios:
tipo de lançamento | descrição |
---|---|
bazel | Um módulo Bazel, com um MODULE.bazel e um CHANGELOG.md |
dart | Um repositório com pubspec.yaml e CHANGELOG.md |
elixir | Um repositório com mix.exs e CHANGELOG.md |
go | Um repositório com um CHANGELOG.md |
helm | Um repositório com Chart.yaml e CHANGELOG.md |
java | Uma estratégia que gera a versão SNAPSHOT após cada lançamento |
krm-blueprint | Um pacote kpt, com 1 ou mais arquivos KRM e um CHANGELOG.md |
maven | Estratégia para projetos Maven, gera versão SNAPSHOT após cada lançamento e atualiza pom.xml automaticamente |
node | Um repositório Node.js, com package.json e CHANGELOG.md |
expo | Um repositório React Native baseado em Expo, com package.json, app.json e CHANGELOG.md |
ocaml | Um repositório OCaml, contendo 1 ou mais arquivos opam ou esy e um CHANGELOG.md |
php | Um repositório com um compositor.json e um CHANGELOG.md |
python | Um repositório Python, com setup.py, setup.cfg, CHANGELOG.md e opcionalmente um pyproject.toml e um <project>/__init__.py |
ruby | Um repositório com version.rb e CHANGELOG.md |
rust | Um repositório Rust, com um Cargo.toml (seja como uma caixa ou espaço de trabalho, embora observe que os espaços de trabalho exigem uma versão orientada por manifesto e o plugin "cargo-workspace") e um CHANGELOG.md |
sfdx | Um repositório com sfdx-project.json e CHANGELOG.md |
simple | Um repositório com version.txt e CHANGELOG.md |
terraform-module | Um módulo terraform, com uma versão no README.md e um CHANGELOG.md |
Há várias maneiras de implantar o lançamento:
A maneira mais fácil de executar o Release Please é como uma ação do GitHub. Consulte googleapis/release-please-action para obter instruções de instalação e configuração.
Consulte Executando a CLI release-please para todas as opções de configuração.
Há um aplicativo probot disponível, que permite implantar o Release Please como um aplicativo GitHub. Consulte github.com/googleapis/repo-automation-bots para obter instruções de instalação e configuração.
Release Please analisa os commits desde sua última tag de lançamento. Ele pode ou não conseguir encontrar suas versões anteriores. A maneira mais fácil de integrar seu repositório é inicializar uma configuração de manifesto.
Release Please fornece várias opções de configuração para permitir a personalização do seu processo de lançamento. Consulte customizing.md para obter mais detalhes.
Release Please também oferece suporte ao lançamento de vários artefatos do mesmo repositório. Veja mais em manifest-releaser.md.
Nossas bibliotecas clientes seguem o cronograma de lançamento do Node.js. As bibliotecas são compatíveis com todas as versões atuais ativas e de manutenção do Node.js.
Bibliotecas cliente direcionadas a algumas versões em fim de vida do Node.js estão disponíveis e podem ser instaladas por meio de npm dist-tags. As tags dist seguem a convenção de nomenclatura legacy-(version)
.
Versões legadas do Node.js são suportadas como melhor esforço:
Versões legadas não serão testadas em integração contínua.
Alguns patches de segurança podem não ser compatíveis com backport.
As dependências não serão mantidas atualizadas e os recursos não serão portados.
legacy-8
: instale bibliotecas cliente a partir desta tag dist para versões compatíveis com Node.js 8.
Esta biblioteca segue o Versionamento Semântico.
Contribuições são bem-vindas! Consulte o Guia de Contribuição.
Para obter mais informações sobre o design da biblioteca, consulte design.
Para problemas comuns e ajuda na solução de problemas de sua configuração, consulte Solução de problemas.
Apache versão 2.0
Veja LICENÇA
Este não é um produto oficial do Google.