Auto: Hotfixes: parches de soporte para menores antiguos y parches

@hiptersmoothie
¿Tiene algún detalle de cómo se implementaría esto / cómo se vería en la práctica?

Además, no estoy seguro de entender qué significa merge into a tag ... ¿podría aclararlo? Tenía entendido que solo se podía crear un RP con una sucursal como objetivo.

No, realmente no he pensado demasiado en el problema.

Además, no estoy seguro de entender qué significa fusionarse en una etiqueta.

La interfaz de usuario me hizo creer que podría fusionarse en una etiqueta, pero después de una revisión más detallada, esto no parece ser posible. Si pudiéramos, esto lo haría posible.

Sin embargo, recordando un poco, creo que esto es lo que estaba pensando:

1. La etiqueta 1.2.3 existe, la versión actual es 2.0
2. PR se convierte en la etiqueta 1.2.3, produce 1.2.3-0 (el 0 es la parte de construcción de semver)

ok, utilizar la parte de compilación de semver definitivamente tiene sentido. 👍

Si no es posible hacer un PR directamente a una etiqueta, entonces este flujo puede requerir que los propietarios de repositorios creen una rama a partir de una etiqueta en la rama ascendente (rama de destino para PR). Sería un poco molesto, pero no estoy seguro de si habría una alternativa mejor. Además, es probable que este tipo de versiones no sea común, por lo que tal vez esto esté bien.

Se podría utilizar un enfoque similar al antiguo soporte principal ( versionBranches ) donde se podría especificar un prefijo de rama en la configuración. Parece que esta función puede estar dirigida más hacia versiones de tipo hotfix, por lo que quizás tenga sentido mantener la configuración separada del soporte principal anterior. ¿Qué piensas?

Un ejemplo de flujo puede verse así:

• el usuario especifica en la configuración automática para compilar usando identificadores de compilación para sucursales con el prefijo hotfix-
• registro de confirmación existente
  <ul> <li>(tag: v2.0.0) (master)<br /> |</li> <li>(tag: v1.2.0)<br /> |</li> <li>(tag: v1.1.0)<br /> |</li> <li>(tag: v1.0.0)<br />

Se podría utilizar un enfoque similar al antiguo soporte principal (versionBranches) donde se podría especificar un prefijo de rama en la configuración.

Me gusta la idea, pero en la práctica no creo que sea tan divertido de usar. Dado que auto libera mucho, terminaría con una gran cantidad de sucursales.

Si no es posible hacer un PR directamente a una etiqueta, entonces este flujo puede requerir que los propietarios de repositorios creen una rama a partir de una etiqueta en la rama ascendente (rama de destino para PR). Sería un poco molesto, pero no estoy seguro de si habría una alternativa mejor. Además, es probable que este tipo de versiones no sea común, por lo que tal vez esto esté bien.

Estoy de acuerdo en que este tipo de liberación está fuera de la norma. que hace que la creación automatizada de ramas sea menos útil. Obtendría mucho ruido (más ramas) sin usarlas tanto, si es que alguna vez.

En cuanto a su flujo propuesto arriba, parece funcionar bien. ¡Sin embargo, es lamentable que no podamos convertir las relaciones públicas en etiquetas! facilitaría mucho este flujo de trabajo.

Pensando en esto, esta característica probablemente necesitará algunas cosas en auto para completarse:

1. Nuevo comando auto hotfix : cuando se ejecute, se lanzará el proyecto con una nueva versión de revisión basada en la última etiqueta de la rama
2. Nueva funcionalidad para auto shipit : Detectamos si estamos en un hotfixBranch y ejecutamos auto hotfix

En cuanto a cómo debería funcionar auto hotfix , podría ir:

1. la forma de next o canary => Nuevo gancho que permite que el complemento controle cómo se publica la revisión, ya sea que sea compatible
2. reutilice los ganchos version y publish y haga que puedan liberar build semver

De las dos opciones, creo que me estoy inclinando hacia 1 ya que llamar a los ganchos version y pubish de una nueva manera podría considerarse un cambio radical. El inconveniente es que algunos de los ganchos no se llamarán afterVersion hace que algunos complementos no funcionen. Sin embargo, esto es actualmente un problema tanto para canary como para next . ya que tampoco llaman a ese gancho. Entonces, algo de lo que no hay que preocuparse de inmediato.

¿Estás interesado en intentar agregar esto?

Me gusta la idea, pero en la práctica no creo que sea tan divertido de usar. Dado que los lanzamientos automáticos son muchos, terminaría con una gran cantidad de sucursales.

Ups, significaba que era similar al antiguo soporte principal en términos de tener una configuración de prefijo de rama. Definitivamente estoy de acuerdo en que la creación automática de ramas crearía demasiado ruido, especialmente con la liberación frecuente, 😆

Pensando en esto, esta característica probablemente necesitará algunas cosas en automático para ser completamente desarrollada:

1. Nueva revisión automática de comandos: cuando se ejecute, se lanzará el proyecto con una nueva versión de revisión basada en la última etiqueta de la rama
2. Nueva funcionalidad para envío automático: Detectar si estamos en una rama de revisión y ejecutar revisión automática

sí. Creo que encapsularía en gran medida los cambios necesarios.

En cuanto a cómo debería funcionar la revisión automática, podría ir:

1. the way of next o canary => Nuevo gancho que permite que el complemento controle cómo se publica la revisión si es compatible
2. reutilizar la versión y publicar hooks y hacerlos capaces de liberar build semver

De las dos opciones, creo que me inclino por 1, ya que llamar a la versión y publicar hooks de una manera nueva podría considerarse un cambio rotundo. El inconveniente es que algunos de los ganchos no se llamarán después de la versión, lo que hace que algunos complementos no funcionen. Sin embargo, esto es actualmente un problema tanto para el canario como para el próximo. ya que tampoco llaman a ese gancho. Entonces, algo de lo que no hay que preocuparse de inmediato.

De alto nivel, creo que 1 también tiene sentido. Necesitaría rastrear el código para comprender mejor qué ganchos se llaman para qué comando, pero si next , canary , & hotfix siguen patrones similares, entonces es probable que los puntos débiles sean más fáciles de resolver más adelante.

¿Estás interesado en intentar agregar esto?

Seguro 👍, estaría feliz de hacerlo.
Probablemente no podré echar un vistazo a la implementación de esto hasta la próxima semana, pero supongo que está bien, ya que este problema no se ha actualizado desde marzo.

¡Impresionante! No hay trabajo planeado en este, así que eres todo tú.

FWIW: iba a intentar construir esto como un complemento haciendo exactamente lo que consideraba una opción inferior: hacer una rama version-MAJOR-MINOR . No parece demasiado ruido sobre nuestro proceso actual, TBH. Ya creamos ramas para cada línea de lanzamiento.

Una parte importante de versionBranches este momento es este complemento :

    this.hooks.beforeCommitChangelog.tapPromise(
      "Old Version Branches",
      async ({ bump }) => {
        if (bump === SEMVER.major && this.config?.versionBranches) {
          const branch = `${this.config.versionBranches}${major(
            await this.hooks.getPreviousVersion.promise()
          )}`;

          await execPromise("git", [
            "branch",
            await this.git?.getLatestTagInBranch(),
          ]);
          await execPromise("git", ["push", this.remote, branch]);
        }
      }
    );

Parece trivial agregar soporte para SEMVER.minor , pero admito que no sé qué otras partes del automóvil pueden necesitar cambiar.

Eso es parte de lo que sucede con la versión anterior, pero luego esta verificación en shipit también tiene que pasar

https://github.com/intuit/auto/blob/f37945b45b7fef6ffdb00ffa0250de449e02b883/packages/core/src/auto.ts#L1442

Lo que luego va aquí y básicamente anula dónde comenzar a calcular la liberación desde

https://github.com/intuit/auto/blob/f37945b45b7fef6ffdb00ffa0250de449e02b883/packages/core/src/auto.ts#L1509

La única consideración que tenemos que hacer con el antiguo menor / parche y no con el mayor es la posible falta de coincidencia de la versión. Sin embargo, con los menores probablemente sea un problema menor

*  (tag: v2.0.0) (master)
| 
*  (tag: v1.1.1)
|
|  *  (tag: v1.1.2) <- Need to add logic to find an available tag 
| /
*  (tag: v1.1.0) (hotfix-feature)
|
*  (tag: v1.0.0)

Entonces, tal vez el comando hotfix no sea necesario. En su lugar, podría intentar un número de versión único. Sin embargo, debería haber alguna validación en torno a esto.

Reglas :

1. no se puede lanzar mayor en ninguna rama de lanzamiento de parche / menor anterior (requerido)
2. no se puede liberar menor en ninguna rama de lanzamiento de parche antiguo (¿tal vez innecesario?)

@hiptersmoothie
¿Sabe cuál es el comportamiento predeterminado ahora si tiene una configuración de ci para construir a partir de una etiqueta anterior, donde la siguiente etiqueta no está disponible?

Supongo que habrá una falla, aunque no estoy seguro de dónde ocurriría este error (¿tal vez al presionar la etiqueta?).

es decir:

*  (tag: v2.0.0) (master)
| 
*  (tag: v1.1.1)
|
|  *   <- what is current behavior if I try to release this commit
| /
*  (tag: v1.1.0) 
|
*  (tag: v1.0.0)

Aparte de hacer cumplir las reglas especificadas por try to unique version number . Para el ejemplo que @hipstersmoothie dio, otros v1.1.2 como una versión de parche de v1.1.1 , pero como el desarrollo no fue lineal, esto no está garantizado. Potencialmente, incluso podría haber un cambio incompatible hacia atrás de v1.1.1 a v1.1.2 ya que es probable que v1.1.2 no tenga los cambios de v1.1.1 . Esto podría agravarse y resultar más confuso si la próxima versión única está a una distancia mayor de v1.1.0 (es decir, ¿qué pasa si la próxima versión única es v1.1.100 ?)

La utilización de la parte de metadatos de compilación de semver limitaría esta confusión, ya que de acuerdo con la especificación de semver, se ignora al calcular la precedencia de la versión. Si se incrementa el número de metadatos de compilación, entonces quizás se pueda usar commit sha en lugar de un número creciente.

En general, el desarrollo de software no es necesariamente lineal, por lo que no estoy seguro de que exista una mejor implementación.

Si queremos generalizar, entonces quizás podríamos tener algún tipo de configuración o gancho para especificar la estrategia para arriba independientemente de la rama (o rama podría ser un parámetro para enganchar).
De esta manera, se podrían usar diferentes implementaciones a través de complementos.

¿Sabe cuál es el comportamiento predeterminado ahora si tiene una configuración de ci para construir a partir de una etiqueta anterior, donde la siguiente etiqueta no está disponible?

Por lo general, las etiquetas no se compilan porque la confirmación tiene [skip ci] en el mensaje

Esto podría agravarse y resultar más confuso si la próxima versión única está a una distancia mayor de la v1.1.0

Es un excelente punto. Definitivamente hace que la parte de los metadatos de compilación de la versión sea la estrategia correcta.

Si queremos generalizar, entonces quizás podríamos tener algún tipo de configuración o gancho para especificar la estrategia para arriba independientemente de la rama (o rama podría ser un parámetro para enganchar).
De esta manera, se podrían usar diferentes implementaciones a través de complementos.

tu publicación me convenció bastante de que encontrar una etiqueta única es un esquema confuso y probablemente no deberíamos.

Quizás si hacemos una mezcla, podría funcionar. Los parches y los viejos menores deberían ser fáciles. Podría funcionar exactamente de la misma manera que oldVersionBranches para mayores:

*  (tag: v2.0.0) (master)
| 
*  (tag: v1.2.0)
|
|  *  (tag: v1.1.5) <- Can merge patched into old minor branch, maybe error when PR has `minor`
| /
*  (tag: v1.1.4) <- branch: version-1.1
|
*  (tag: v1.0.0)

Entonces solo necesitamos hacer la parte de metadatos de compilación para parchear parches.

Con las opciones from y useVerion fusionadas, ¿hay una forma incorporada de hacer una revisión? Solo tenía que hacer uno hoy y opté por hacerlo dolorosamente manualmente.

Por contexto, mi proyecto está en 7.7. Un consumidor importante de nuestro proyecto está lanzando actualmente una versión que está en 7.5, encontró un problema y requirió 7.5.1 para que no tuvieran que volver a controlar todo a mitad del lanzamiento. No es óptimo, pero sucede ocasionalmente.

Todavía no hay forma de hacer esto que yo sepa sin la intervención manual. Creo que alguien internamente aquí en intuit planea agregar esto eventualmente. Estoy de acuerdo en que esta es una característica que falta mucho en auto.

¡Increíble de escuchar! Gracias 🙏

Nosotros (@ 10hendersonm y yo) desarrollamos una solución para esto, pero es bastante
involucrado. ¡Sin embargo, solo usa auto y complementos!

Acabamos de corregir 7.2.1, 8.1.1 y 8.2.2 de nuestro proyecto utilizando solo RP
(muy cuidadosamente).

¿Podríamos investigar cómo compartir esto si la gente está interesada?

El jueves 14 de enero de 2021 a las 7:27 p.m., Matt Felten [email protected] escribió:

¡Increíble de escuchar! Gracias 🙏

-
Estás recibiendo esto porque hiciste un comentario.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/intuit/auto/issues/1054#issuecomment-760583830 , o
darse de baja
https://github.com/notifications/unsubscribe-auth/AACI3Q6RKDONYJVH6UWUPFLSZ6KZNANCNFSM4LFJ4ULQ
.

¡Me interesaría mucho!

¡Hola a todos! Estoy interesado en contribuir con esto. Mi propuesta es la siguiente:

1. En general, auto intentará respetar cualquier rama version-* . Por ejemplo, una combinación de parche de cualquier rama en version-1.1.4 generará un lanzamiento de la versión 1.1.5 . Si esa versión ya se ha creado, la versión de NPM o la etiqueta de Git fallarán, pero ese es un caso de error normal y esperado.
2. Podemos actualizar versionBranches para aceptar "major" | "minor" | "patch" , lo que generará posibles ramificaciones de hotfix según lo que especifique. Esto le permite elegir la compensación entre la necesidad de crear manualmente una sucursal version-* y terminar con demasiadas sucursales para mantener cuando no necesita arreglos

¿Pensamientos?

pero ese es un caso de error normal y esperado \

Todavía espero que esto cree algún tipo de versión. Recientemente tuve un caso en el que quería lanzar una revisión de una confirmación específica para no incorporar nada más. Creo que en este caso podríamos usar la parte de compilación de semver de la conversación anterior.

Podemos actualizar versionBranches para aceptar "major" | "menor" | "parche"

La configuración actual puede ser true o una cadena para prefijar las ramas principales. Creo que la nueva configuración debería verse como

{
  "versionBranches": {
      "branchPrefix": "version-",
      "types": ["major", "minor"] // defaults to just major   
   }
}

La última pregunta a responder sigue siendo hotfix hook o call version + publish hooks mirando el código de la implementación de la rama de la versión anterior actual, hacemos la opción 2 y llamamos a version + publish (y creo que esto se publica erróneamente en la última etiqueta).

@lshadler Muchos necesitamos emparejarnos en esto por un tiempo para encontrar el mejor enfoque.

@bmuenzenmeyer ¿Puede dar una descripción general de su enfoque?

Cuanto más pienso en la implementación, más creo que esto necesitará v11 y más contexto agregado a los comandos de versión y publicación.

Para las versiones anteriores, necesitamos que se ejecute la última canalización completa con el registro de cambios, afterVersion y todos o sus ganchos llamados durante una versión más reciente.

Probablemente deberíamos hacer que los próximos lanzamientos tengan la misma versión después de que la versión se publique después del flujo de publicación más reciente. Eso también puede ser parte de v11. Debe coincidir con el último flujo de trabajo para que pueda agregar una automatización similar.

El flujo de trabajo de Canary puede permanecer igual, ya que no se compromete nada para un canary y ya puedes tocar el anzuelo para hacer más cosas.

Hola a todos, con la locura de este último año, lamentablemente este tema se me ha escapado.

Con respecto a los diferentes enfoques, creo que puede ayudar considerar los diferentes casos de uso que resuelven estas características. En mi opinión, puedo ver 2 casos de uso:

• (1) soporte a largo plazo para una rama antigua (es decir: versión principal antigua)
• (2) soporte a corto plazo para una versión específica (es decir, revisión)

Según esta conversación, creo que tiene sentido tener enfoques distintos para cada uno de esos casos de uso.

(1) Para el soporte a largo plazo de una rama / pista de lanzamiento, creo que versionBranches debería poder resolver. Si existe el deseo de extender este comportamiento para versiones menores (como algunos han mencionado anteriormente), entonces eso podría ser una mejora para esa funcionalidad.

(2) Para soporte / revisión a corto plazo, basado en los subprocesos anteriores, creo que debería haber una forma estándar para que los usuarios siempre usen parte de la compilación de semver para generar una versión de revisión. Esto proporciona un comportamiento coherente para que lo utilicen los propietarios de código y evita algunos escenarios complicados de casos de esquina. Para este caso, creo que se podría usar un nuevo comando de revisión y un enlace. Esta podría ser una mejora distinta. En general, este caso de uso debería ser relativamente raro, ya que se debería animar a los consumidores a utilizar las últimas versiones si es posible.

edit _ (Para el caso de uso a corto plazo, potencialmente versionBranches config podría extenderse para permitir un parámetro / alternar / marcar que denote si respetar las etiquetas semver para las ramas version- o utilizar siempre la parte de compilación de semver e ignore las etiquetas de esas ramas) _

¿Hay otros casos de uso además de estos 2 que deberían tenerse en cuenta?

¿Deben considerarse diferentes enfoques para diferentes casos de uso?

(Además, todavía puedo ayudar con algunos de estos cambios, pero definitivamente no quiero bloquear a nadie más para que no realice cambios para esto)

también, un pensamiento tangencial para patrones de ramificación:

auto generará una etiqueta git (lanzamiento) para los lanzamientos. Esto significa que una referencia de git válida se envía a github. Para el caso de uso de soporte a corto plazo (es decir, rama de corta duración / rama de revisión), esto significa que un usuario puede eliminar la rama de corta duración después de que se haya enviado una etiqueta de lanzamiento / git.

• dada una rama maestra con las siguientes etiquetas
  <ul> <li>(tag: v1.3.0) (master)<br /> | </li> <li>(tag: v1.2.3)<br />

Para las ramas de corta duración, puede ser bueno documentar el patrón de ramificación anterior al agregar una característica. Personalmente, descubrí que muchos no saben que puede eliminar la rama y aún tener una referencia a la nueva confirmación, lo que puede ayudar a diferentes proyectos a reducir el desorden de las ramas de corta duración.

Recientemente estuve jugando con el código para utilizar la parte de compilación de semver para crear compilaciones. Mientras lo hacía, me encontré con el caso de uso en el que la última versión de github no era necesariamente la versión semántica más reciente / más alta.

Por ejemplo, en el ejemplo mencionado aquí: https://github.com/intuit/auto/issues/1054#issuecomment -780286683, la última versión de github se mostraría como v1.2.3+1 ya que se creó temporalmente después de la más alta versión versión semántica: v1.3.0 .

Dado que algunos lugares en el código hacen referencia a getLatestRelease , esto puede llevar a comportamientos variados si la canalización no establece explícitamente el parámetro from . es decir:

• lo que se incluye en las notas de la versión
• lo que la versión anterior se calcula como
• potencialmente rompiendo la funcionalidad si no se puede acceder a la última versión de github desde la confirmación HEAD

No lo he probado, pero creo que estos tipos de escenarios también serían accesibles a través del comportamiento existente de versionBranches . Creo que esto está relacionado con el comentario sobre qué flujos deberían generar etiquetas git / versiones de github:

La última pregunta a responder sigue siendo hotfix hook o call version + publish hooks mirando el código de la implementación de la rama de la versión anterior actual, hacemos la opción 2 y llamamos a version + publish (y creo que esto se publica erróneamente en la última etiqueta).

En términos de resolución, es probable que este problema se pueda resolver independientemente de la refactorización del gancho reemplazando la lógica getLatestRelease por:

• (1) obtenga versiones de github usando listReleases y luego ordene para encontrar la versión de lanzamiento más alta (sin prelanzamiento o partes de compilación) que sea accesible
• (2) o busque etiquetas git y luego ordene para encontrar la versión de lanzamiento más alta (sin prelanzamiento o partes de compilación) que sea accesible

La diferencia aquí sería si auto ve los lanzamientos de github o las etiquetas de git como fuente de verdad, lo cual está relacionado con la discusión https://github.com/intuit/auto/discussions/1867#discussioncomment -684192.

Inicialmente me inclinaría hacia (2), ya que

• (a) finalmente buscamos la referencia de git (etiqueta) y no los otros elementos de la versión de github
• (b) reduciría el número de llamadas a la red

@hipstersmoothie ,
Si necesitamos modificar la lógica getLatestRelease , ¿qué piensa sobre (1) usar versiones de github frente a (2) usar etiquetas git frente a (3) algo más?

Sí, para que funcione el auto de múltiples paquetes, será necesario refactorizar todas las últimas novedades de GitHub en solo etiquetas. 2 es definitivamente la opción a seguir para hacer este trabajo.