Automatizando lançamentos com GitHub Actions: Integração do Semantic Release e geração de Changelog
Neste artigo, veremos como configurar o GitHub Actions para gerar o arquivo CHANGELOG usando o semantic-release.
Mas o que é o arquivo CHANGELOG?
Um changelog é um arquivo que lista, em ordem cronológica, todas as alterações realizadas em um projeto, geralmente seguindo a numeração das versões. Esse recurso é valioso porque fornece um resumo claro do que foi modificado em cada versão, ajudando tanto desenvolvedores quanto clientes a acompanharem as melhorias, correções de bugs e novas funcionalidades. A seguir, apresentamos um exemplo de como um changelog pode ser organizado:
Informações essenciais
Antes de iniciarmos a configuração, é importante termos a consiência que as mensagens do commit são importantes para entendermos o que foi aplicado. Na imagem acima vemos que as mensagens não estão lá aquelas coisas e fica difícil entender o que foi feito. Uma dica é: ao ler a mensagem de um commit, ela precisa dar sequência à frase:
Se eu aplicar este commit ele vai ...
Por exemplo, a mensagem de commit “adicionar suporte para dark/light mode”. Agora, se lermos “Se eu aplicar este commit, ele vai adicionar suporte para dark/light mode”, confirmamos que a mensagem está boa, pois faz sentido dentro dessa estrutura de frase.
Embora façamos a configuração pela pipeline, caso queira fazer isso rapidamente, o seguinte comando irá ajudar:
git log --pretty="- %s" > CHANGELOG.md
Esse comando do GIT faz com que os commit sejam mostrados de uma forma mais organizada. Em seguida, adicionamos para o arquivo CHANGELOG.md
O que é o semantic-release?
Em rápidas palavras, semantic-release é uma ferramenta que automatiza o gerenciamento de versões e a geração de changelogs se baseando nas mensagens de commit. Ela usa as convenções de mensagens de commit, como o Conventional Commits, para definir o tipo de versão (major, minor ou patch) a ser incrementada e gerar automaticamente o changelog.
Como configurar a sua Github Actions?
Vá em seu perfil, na opção Settings > Developer Settings. Em Personal access tokens e crie um token do tipo Tokens (classic).
As permissões que iremos precisar estão selecionadas na imagem abaixo:
OBS: Caso tenha alguma permissão desnecessária, fique a vontade para me informar.
Após criado o token, deixe-o salvo e vá para o projeto que deseja configurar o Github Actions, em Settings:
Agora vá em Secrets and variables > Actions e adicione uma nova secret com o nome de GH_TOKEN e o valor dessa secret será o token que criamos anteriormente.
Agora crie a sua Action baseado no seu projeto e adicione o seguinte trecho:
name: pipeline
on:
push:
branches:
- main
jobs:
main:
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v4
with:
persist-credentials: false
# --- Adcionar trecho ----
- name: Semantic Release
uses: cycjimmy/semantic-release-action@v4
env:
GH_TOKEN: ${{ secrets.GH_TOKEN }}
# --- Adcionar trecho ----
e na raiz do seu projeto adicione o arquivo .releaserc com o seguinte conteúdo:
{
"branches": [
"main"
],
"plugins": [
"@semantic-release/commit-analyzer",
"@semantic-release/release-notes-generator",
[
"@semantic-release/changelog",
{
"changelogFile": "CHANGELOG.md"
}
],
[
"@semantic-release/git",
{
"assets": [
"CHANGELOG.md"
]
}
],
"@semantic-release/github"
]
}
Esse arquivo será o responsável por gerar o CHANGELOG diretamente no projeto. Após rodar a primeira vez, puxe as alterações e vá na raiz do seu projeto e você verá que o arquivo CHANGELOG.md foi criado com os commits que existe no projeto. Vale ressaltar que, todo commit deve seguir a estrutura definida pelo conventional commits para que haja o gatilho de gerar uma nova versão.
Referências
