Auto: Lançamentos sendo gerados mesmo que o rótulo sem lançamento esteja presente
Descreva o bug
Em um de nossos repositórios, estamos vendo implantações consistentes quando não esperamos que nenhuma implantação aconteça. Essa rotatividade ocorre especificamente quando @renovatebot faz uma solicitação pull para atualizar dependências, portanto, _pode_ ser como está lidando com o processo de confirmação / fusão.
Aqui está um exemplo de PR onde o selo sem lançamento está presente ( Version: Trivial em nosso caso), mas o lançamento ainda está acontecendo. Aqui estão os resultados de
@hipstersmoothie atualizarei com um modo verboso executado quando tiver uma chance. Se eu puder perseguir algo específico, abrirei um PR.
Reproduzir
Eu ainda não identifiquei o que há em comum aqui. Este é o único lugar em nossa organização onde @renovatebot mescla automaticamente as atualizações de código para que possa estar relacionado a isso.
Comportamento esperado
Nenhuma liberação deve ser acionada.
zephraph
Todos 11 comentários
Tive outra instância dele em um repo diferente. https://github.com/artsy/palette/compare/v2.25.10...v2.25.11. Isso também foi gerado automaticamente, mas por perigo, em vez de @renovatebot. Talvez seja a maneira como os bots mesclam PRs?
zephraph
em 15 jan. 2019
Poderia ser. as etiquetas de liberação de salto requerem que o cabeçote tenha a etiqueta associada.
Deve procurar provavelmente o último PR ao invés do último commit.
hipstersmoothie
em 15 jan. 2019
Linhas relevantes https://github.com/intuit/auto-release/blob/83463e3f468a6d5e265cd5c720530bc5ac637365/src/semver.ts#L59
hipstersmoothie
em 15 jan. 2019
Hmmm ... sim. Então, quando eu estava construindo isso, olhei entre o hash principal e o hash do último lançamento e usei isso para descobrir quais eram os PRs.
https://github.com/artsy/reaction/pull/1407/files#diff -ff397bdd24eed50e2a2cade2792a9d80R100
zephraph
em 15 jan. 2019
@zephraph Só para deixar claro, é esta a situação que está acontecendo?
gitlog:
- Alguns enviam um bot ou pessoa feita após a fusão
- o commit que tem o PR com o rótulo
skip-release
resultado:
auto não skip-release porque o commit 2 não está no topo do gitloh
hipstersmoothie
em 17 jan. 2019
Não houve um commit feito após a fusão. Parece ser a própria fusão. Quando um bot se funde (acho que é isso, mas pode ser uma coincidência) um PR, então um lançamento acontece mesmo quando um rótulo skipReleaseLabels está presente. Posso encontrar mais exemplos, se necessário.
Aqui está o exemplo mais recente (semelhante ao anterior).
- https://github.com/artsy/renovate-config/pull/164 foi criado por renovate
- Renovar atribuído
Version: Trivialao PR (que está em skipReleaseLabels ) - Renovar mescla o PR automaticamente
- Um novo lançamento é cortado apesar de haver uma gravadora
skipReleaseLabelspresente
zephraph
em 17 jan. 2019
Esta mesclagem de PR não tem um número de PR no assunto de commit
Todos os que funcionam têm um número de RP
auto depende deste número na mensagem de confirmação para obter o número PR:
Portanto, algo parece estar acontecendo ao mesclar esses PRs. É um rebase que está acontecendo?
hipstersmoothie
em 17 jan. 2019
precisamos de uma função que retorne o pr associado a um SHA, mas estou tendo problemas para encontrar um método octokit apropriado
hipstersmoothie
em 18 jan. 2019
hmm foi apenas percorrido o caminho de tentar corresponder o commit no master ao commit no PR, mas parecem ter SHAs diferentes.
Isso é super decepcionante. Agora não tenho ideia de como podemos combinar esses compromissos com seus PRs
hipstersmoothie
em 18 jan. 2019
merge_commit_sha para o resgate
hipstersmoothie
em 18 jan. 2019
@zephraph isso deve ser corrigido em v2.5.6 . Avise-me se você ainda tiver problemas.
hipstersmoothie
em 18 jan. 2019
Questões relacionadas
aleclarson
·
14Comentários
zephraph
·
10Comentários
zephraph
·
12Comentários
hipstersmoothie
·
11Comentários
tunnckoCore
·
4Comentários
Comentários muito úteis
@zephraph isso deve ser corrigido em
v2.5.6. Avise-me se você ainda tiver problemas.