CI, E2E e release por tag - #1
Merged
Merged
Conversation
Dois workflows. O CI roda em toda PR e em todo push na dev, em windows-latest — o alvo é Windows: os testes lidam com caminhos do Windows e o E2E sobe o Electron de verdade. Ele faz typecheck, lint, formatação, os testes de unidade e a suíte Playwright, e tem um job que cobra a regra das branches: PR para a main só pode vir da dev. O release sai do merge da dev na main. A versão vem do package.json e as notas vêm do patchnotes.json, novo aqui: escritas à mão, em português, e validadas com rigor (semver, ordem, datas reais, categorias conhecidas, itens de uma linha) porque um erro ali só apareceria na hora de publicar. Se a tag v<versao> já existe, o run não faz nada — um push na main que não bumpou a versão não republica nem sobrescreve release alguma. Publicar uma versão é subir o version do package.json e escrever as notas dela na mesma PR.
Os três rulesets que passam a aplicar o fluxo do lado do GitHub: a main só por PR com o CI verde e merge commit (para guardar o histórico da dev), a dev sem force-push e sem remoção, e as tags de versão imutáveis. Nenhum deles tem exceção de bypass, nem para o dono do repositório, e nenhum atrapalha o release: o workflow cria a tag, e criar não é mover nem apagar.
O CONTRIBUTING traz o fluxo, o ambiente — inclusive como mexer no app inteiro sem WSL instalado, pelo modo de demonstração — e as convenções que a revisão cobra: comentário explica o porquê, contrato IPC é a fronteira, seletor de teste sai de papel e nome acessível. O SECURITY descreve o modelo de confiança do app (desktop local, renderer sem Node, todo canal validado com Zod nas duas direções) e lista o que conta e o que não conta como vulnerabilidade, para não gastar o tempo de quem reporta: bug do wslc ou do SDK é da Microsoft, e o app executar o comando que o usuário digitou é a função dele. Código de Conduta: Contributor Covenant 2.1, tradução oficial em pt-BR. Templates de issue em formulário. O de bug pergunta o motor, a versão do WSL e se o caso reproduz no modo de demonstração — essa última já separa problema de UI de problema de container. O de ideia pede o incômodo antes da solução e se o wslc suporta aquilo, porque a UI não inventa o que a CLI e o SDK não expõem.
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
1 participant
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 que muda
.github/workflows/ci.yml): toda PR e todo push nadev, emwindows-latest— typecheck, lint, formatação, unidade, e o E2E do Playwright contra o app Electron compilado, com o relatório subindo como artefato.mainsem vir dadev.patchnotes.json: as notas de cada versão, escritas à mão e em português, com validação rígida (semver, ordem decrescente, datas reais, categorias conhecidas, itens de uma linha). Entra nonpm run checke no CI..github/workflows/release.yml): sai do merge dadevnamain. Valida as notas, roda o CI inteiro no estado que vai virar tag, cria a tag anotadav<versao>e publica a release com o corpo gerado dopatchnotes.json. Se a tag já existe, o run não faz nada.Publicar uma versão passa a ser: subir o
versiondopackage.jsone escrever as notas dela nopatchnotes.json, na mesma PR.Checklist
devnpm run checkpassa (typecheck, lint, formatação, testes epatchnotes.json)patchnotes.jsoncom a entrada de 0.1.0versiondopackage.jsonsubido — não; 0.1.0 continua sendo a versão a lançar