fix: a nota de release era extraída, passada, e descartada - #32
Merged
Conversation
changelog.disable desliga o pipe que carrega o --release-notes. Eu liguei os dois no mesmo commit: a nota saía do CHANGELOG, chegava ao goreleaser como caminho de arquivo, e era jogada fora sem erro. A v0.1.2 foi publicada com o corpo contendo apenas o rodapé, e o release ficou verde. O pipe volta ligado. Os filtros abaixo dele nunca são usados enquanto o flag existir — estão ali para o caso de ele sumir. Duas verificações, porque a falha foi silenciosa dos dois lados. Antes de publicar, release-check falha se as duas configurações se anularem de novo, e isso roda em todo PR. Depois de publicar, o workflow busca o corpo da release e confere que ele contém a seção que passou: é o único artefato de release que ainda dá para corrigir, e essa checagem pega qualquer quebra futura do mecanismo, não só esta causa.
…join mining O arquivo citava três versões diferentes: v0.1.1 no bloco de destaque, v0.1.1 na gravação de saída, e um .deb 0.1.0 nas instruções de instalação — apontando para um artefato que não era mais o último. Injetar a versão por build só automatizaria um problema que não precisa existir. O bloco de destaque não nomeia mais versão, porque o badge já diz pre-release e o CHANGELOG carrega as versões, e a instalação passa a usar glob. Sobra a gravação, que imprime a própria versão porque a ferramenta imprime — e sozinha no arquivo ela não contradiz nada. O risco ali não é o número envelhecer, é o formato do relatório mudar, então isso virou passo em RELEASING.md. O README dizia que era questão em aberto se o baixo rendimento da mineração de junções era dos schemas ou do extrator. Para o corpus público dá para fechar sem subir banco: o GitLab declara 336 funções e três delas contêm um JOIN, mais quinze views; o Discourse, sete funções sem nenhum JOIN e uma view. Não há o que minerar. Um structure.sql é definição de schema, e SQL analítico não mora ali. Isso agora aparece também junto da afirmação que ele relativiza, em vez de 270 linhas depois — e o link para o corpus, que estava quebrado desde antes, volta a resolver.
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.
Dois consertos independentes, um deles achado ao conferir a própria v0.1.2.
O mecanismo de nota de release estava quebrado
changelog.disable: truedesliga o pipe do goreleaser que carrega o--release-notes. Eu liguei as duas coisas no mesmo commit, e elas se anulam: a nota saía do CHANGELOG, chegava ao goreleaser como caminho de arquivo, e era descartada — sem erro, sem aviso, release verde.A v0.1.2 foi publicada com o corpo contendo apenas o rodapé. Verificado no código da versão que o CI usou (
internal/pipe/changelog/changelog.go, v2.17.1):Skip()devolve verdadeiro quandoChangelog.Disable, e é dentro deRun()que o arquivo é lido paractx.ReleaseNotes.O corpo da release v0.1.2 já foi corrigido — é o único artefato publicado que ainda dá para consertar.
Duas verificações, porque a falha foi silenciosa dos dois lados:
make release-check— que o CI roda em todo PR — falha se o workflow passar--release-notesenquanto o.goreleaser.yamldesligar o estágio que o lê. Verificado por mutação.O README citava três versões diferentes
v0.1.1no bloco de destaque,v0.1.1na gravação de saída, epgfathom_0.1.0_linux_amd64.debna instalação — apontando para um artefato que não era o mais recente.A correção não é injetar a versão no build, que só automatizaria um problema evitável: os números que envelhecem saíram. O bloco de destaque não nomeia versão (o badge já diz
pre-release, o CHANGELOG carrega as versões) e a instalação usa glob. Sobra a gravação, que imprime a versão porque a ferramenta imprime — sozinha no arquivo, não contradiz nada. O risco real ali é o formato do relatório mudar, e isso virou passo noRELEASING.md.A questão em aberto do join mining, fechada para o corpus público
O README dizia ser questão em aberto se o baixo rendimento era dos schemas ou do extrator. Dá para responder sem subir banco:
JOINno corpoNão há o que minerar. Um
structure.sqlpublicado é definição de schema, e SQL analítico não mora ali. Isso agora aparece também junto da afirmação que relativiza, em vez de 270 linhas depois.De quebra: o link
#the-public-corpusno bloco de destaque estava quebrado desde antes — a seção se chama "The measured corpus".