chore: automatizar tag e GitHub Release por versao - #14
Merged
Conversation
Ate agora o projeto nunca foi tagueado (backend/package.json ja passou por 1.0.0 -> 2.0.0 -> 2.1.0 sem nenhuma tag correspondente no git). Adiciona .github/workflows/release.yml: ao dar push na main com uma mudanca em backend/package.json, cria a tag vX.Y.Z (se ainda nao existir) e publica uma GitHub Release com notas geradas automaticamente a partir dos PRs mergeados desde a ultima. Nao decide o bump sozinho - quem decide patch/minor/major e o PR que muda a versao; isso aqui so oficializa com tag + release. README: badge de "release" (le a ultima tag publicada, separado do badge de "versao" que ja lia backend/package.json em tempo real) e secao Versionamento explicando o fluxo. CONTRIBUTING.md aponta pra la.
Contributor
There was a problem hiding this comment.
Pull request overview
Este PR introduz automação de versionamento no repositório, criando tag Git e GitHub Release a partir da versão declarada no backend/package.json, além de documentar o fluxo de versionamento para contribuintes.
Changes:
- Adiciona workflow de release que cria tag
vX.Y.Ze publica GitHub Release com notas geradas automaticamente. - Atualiza o README com badge de última release e seção de “Versionamento”.
- Atualiza o CONTRIBUTING com instrução para bump sincronizado de versão (backend/frontend) apontando para o README.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
.github/workflows/release.yml |
Novo workflow para criar tag e GitHub Release automaticamente após mudanças de versão na main. |
README.md |
Adiciona badge de release e documenta o fluxo de versionamento/lançamento. |
CONTRIBUTING.md |
Orienta contribuidores sobre bump de versão e aponta para a seção de Versionamento no README. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Comment on lines
+40
to
+58
| - name: Ja existe tag pra essa versao? | ||
| id: check_tag | ||
| run: | | ||
| if git ls-remote --exit-code --tags origin "refs/tags/v${{ steps.version.outputs.version }}" >/dev/null 2>&1; then | ||
| echo "exists=true" >> "$GITHUB_OUTPUT" | ||
| else | ||
| echo "exists=false" >> "$GITHUB_OUTPUT" | ||
| fi | ||
|
|
||
| - name: Criar tag e GitHub Release | ||
| if: steps.check_tag.outputs.exists == 'false' | ||
| env: | ||
| GH_TOKEN: ${{ secrets.GITHUB_TOKEN }} | ||
| run: | | ||
| git tag "v${{ steps.version.outputs.version }}" | ||
| git push origin "v${{ steps.version.outputs.version }}" | ||
| gh release create "v${{ steps.version.outputs.version }}" \ | ||
| --title "v${{ steps.version.outputs.version }}" \ | ||
| --generate-notes |
Comment on lines
+15
to
+18
| permissions: | ||
| contents: write | ||
|
|
||
| jobs: |
Merged
2 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
O problema
O projeto já passou pelas versões
1.0.0→2.0.0→2.1.0embackend/package.json, mas nunca teve uma tag git correspondente. Sem tag, não há release, changelog, nem forma de apontar "o que mudou entre a v2.0 e a v2.1" — o histórico de versões só existe implicitamente nogit log.O que este PR adiciona
.github/workflows/release.yml— dispara em todo push namainque mudabackend/package.json:backend/package.json.frontend/package.jsonestá na mesma versão (falha com erro claro se não estiver).vX.Y.Zainda não existe, cria e publica a tag, e cria uma GitHub Release com notas geradas automaticamente (gh release create --generate-notes, agrupa por PRs mergeados desde a última release).Não decide sozinho se é patch/minor/major — isso continua sendo decisão de quem faz o PR, bumpando os dois
package.json. O workflow só oficializa com tag + release quando esse bump chega namain.CI: novo job
version-sync(adicionado emci.ymlvia o PR #11, que é onde esse arquivo já existe) falha o build se backend e frontend estiverem com versões diferentes — pega o esquecimento antes do merge, não só na hora de tagear.README: badge de "release" (lê a última tag publicada — hoje nenhuma, então aparece vazio até a primeira release sair) ao lado do badge de "versão" que já existia (lê
backend/package.jsonem tempo real). Nova seção Versionamento documentando o fluxo.CONTRIBUTING.mdaponta pra lá.Por que essa abordagem (e não semantic-release/release-please)
Este projeto não segue Conventional Commits com rigor suficiente pra confiar em bump automático por análise de mensagem de commit (embora o
CONTRIBUTING.mdrecomende o formato). Preferi manter o controle do bump explícito no PR — mais simples, mais previsível, sem precisar de config adicional pra sincronizar doispackage.jsonnum mesmo "release" — e automatizar só a parte mecânica que sempre foi esquecida: tag e release.Test plan
version-syncdo CI propositalmente dessincronizando os doispackage.jsonnum PR de teste (deve falhar)