Detector de "breaking changes"

[m1guelpf]

Idea

• Bot para GitHub/GitLab que analiza las Pull Requests y comenta si encuentra breaking changes.

MVP

• Lee un fichero de configuración para decidir que cambios son aceptables y cuales no
• Analiza los diffs de las PRs para detectar si un cambio es compatible
• Comenta si encuentra un cambio no compatible

Features adicionales

• Cambia automáticamente de rama (branch) a otra que si acepte cambios compatibles
• Genera automáticamente una guía de actualización con todos los cambios

Use case

Proyectos open-source sobre todo

[dcarral]

@m1guelpf ¿Cómo te gustaría decidir qué cambios son aceptables y cuáles no? 🤔

[m1guelpf]

@dcarral Idealmente esto sería configurable para cada repo

[dcarral]

Pero… ¿cómo? Por ejemplo, en un supuesto config/[breaking | compatible]_changes...:

[breaking | compatible]_changes:
   ?

¿Podrías poner un ejemplo? Hoy en día es bastante habitual trabajar con diferentes herramientas integradas en la deployment pipeline con la habilidad para detectar y comentar sobre diferentes aspectos (e incluso sugerir mejoras o auto-corregirlos), por lo que me genera mucha curiosidad si lo que tienes en mente va en esa línea, o estaríamos hablando de algo diferente 👌🏾

[m1guelpf]

@dcarral Hoy en día la convención para estas cosas es tener un .breaking.yml en el repo que pueda definir configuraciones como un regex de archivos que están considerados breaking change o otras opciones a medida que se vaya desarrollando la aplicación. Otra opción sería ofrecer un dashboard en algún sitio donde se puedan configurar estas mismas opciones.

Inicialmente esta idea iba enfocada a frameworks como Laravel que tienen que constantemente mencionar en las PRs que el archivo que se está editando (una interfaz en la mayoría de casos) no puede ser cambiado en cierto branch, pero se podrían ir añadiendo reglas más avanzadas poco a poco.

[dcarral]

Curioso, ¿puedes compartir link a algún proyecto usando esos breaking.yml que comentas?

[m1guelpf]

@dcarral Ahora mismo ninguno, sería un ejemplo de configuración siguiendo el estándar de configurar diferentes integraciones en archivos .yml

[dcarral]

Hmm, vaya. No acabo de entender del todo… ya te digo que he trabajado con todo tipo de bases de código (ninguna de ellas en PHP, eso sí) y deployment pipelines y nunca he visto una casuística similar. A ver si coincidimos en alguno de los próximos eventos y, más allá de conocernos, me puedes comentar/explicar con más calma qué problema trata de resolver esto… que si no podemos estar aquí hasta el día del juicio final :) ¡Saludos!

[dinigo]

Parece algo así como una colección de tests que sean "core". Como un contrato de compatibilidad que se define al principio
de cada que versión mayor y no pueda modificarse. Diferentes lenguajes y frameworks tienen diferentes herramientas de testing aunque la mayoría implementan APIs de reporting. Veo lo que propones y parece interesante aunque en mi experiencia esto se implementa como un batch de tests.

Habitualmente se puede indicar en los tsts si se permite fallar individualmente y aún así pasar el test general. Supongo que se podría definir como obligatorio u opcional en un archivo aparte.