Auto: Publicaciones que se generan a pesar de que la etiqueta de no publicación está presente

Tuve otra instancia en un repositorio diferente. https://github.com/artsy/palette/compare/v2.25.10...v2.25.11. Esto también fue automático, pero por peligro en lugar de @renovatebot. ¿Quizás es la forma en que los bots fusionan las relaciones públicas?

podría ser. las etiquetas de liberación de salto requieren que el cabezal tenga la etiqueta asociada.

Probablemente debería buscar el último PR en lugar de la última confirmación.

Líneas relevantes https://github.com/intuit/auto-release/blob/83463e3f468a6d5e265cd5c720530bc5ac637365/src/semver.ts#L59

Hmmm ... sí. Entonces, cuando estaba construyendo esto, miré entre el hash de la cabeza y el hash de la última versión y lo usé para averiguar cuáles eran los PR.

https://github.com/artsy/reaction/pull/1407/files#diff -ff397bdd24eed50e2a2cade2792a9d80R100

@zephraph Para ser claros, ¿es esta la situación que está sucediendo?

gitlog:

1. Algunos cometen un bot o una persona después de que te fusionaste
2. el compromiso que tiene el PR con la etiqueta skip-release

resultado:

auto no skip-release porque la confirmación 2 no está en la parte superior de gitloh

No hubo un compromiso que se realizó después de la fusión. Parece ser la fusión en sí. Cuando un bot se fusiona (creo que es eso, pero eso podría ser una coincidencia) con un PR, se produce un lanzamiento incluso cuando hay una etiqueta skipReleaseLabels presente. Puedo encontrar más ejemplos si es necesario.

Este es el último ejemplo (similar al anterior).

1. https://github.com/artsy/renovate-config/pull/164 fue creado por renovar
2. Renovar asignado Version: Trivial al PR (que está en skipReleaseLabels )
3. Renovar fusiona el RP automáticamente
4. Se corta una nueva versión a pesar de que hay una etiqueta skipReleaseLabels presente

Esta combinación de relaciones públicas no tiene un número de relaciones públicas en el asunto de la confirmación

Todos los que funcionan tienen un número de PR.

auto basa en este número en el mensaje de confirmación para obtener el número PR:

unir:
https://github.com/intuit/auto-release/blob/5cbccf46a9b49b12210325e7332d9f5c26b44ed1/src/log-parse.ts#L73

calabaza:
https://github.com/intuit/auto-release/blob/5cbccf46a9b49b12210325e7332d9f5c26b44ed1/src/log-parse.ts#L94

Entonces, algo parece estar sucediendo al fusionar esos RP. ¿Es un rebase lo que está sucediendo?

necesitamos una función que devuelva el pr asociado con un SHA pero tengo problemas para encontrar un método de octokit apropiado

hmm simplemente siguió el camino de intentar hacer coincidir la confirmación en el maestro con la confirmación en el PR, pero parece que tienen diferentes SHA.

Esto es muy decepcionante. Ahora no tengo ni idea de cómo podemos hacer coincidir estos compromisos con sus RP

merge_commit_sha al rescate

@zephraph, esto debería arreglarse en v2.5.6 . ¡Avísame si aún tienes problemas!