Te invito a compartir ideas sobre posibles flujos de trabajo de CI, que ejecutarían pruebas en plugins no oficiales proporcionados por la comunidad.
Algunas comunidades dependen en gran medida de plugins, sin un mantenimiento establecido:
Dado que las pruebas de plugins dependen de una instalación de Discourse como campo de pruebas, me pregunto cómo podría ser un flujo de trabajo de CI compatible con la comunidad.
Algunos plugins incluyen especificaciones, como la implementación de @angus de activitypub, que, según entiendo, permiten realizar pruebas para CI.
Actualmente, pienso en dos formas posibles de mejorar las pruebas de plugins no oficiales, dependiendo de las especificaciones / pruebas incluidas en el código fuente del plugin:
a) construir alguna maquinaria que ayude a los mantenedores del sitio a ejecutar pruebas en un entorno de staging.
b) tener algún servicio que bifurque una imagen de prueba predefinida para informar sobre las pruebas ejecutadas en el último código publicado del plugin.
¿Qué opinas?
¿Me he perdido algún flujo de trabajo ya establecido?
Además de la CI con pruebas de backend y frontend, que la mayoría de los plugins de Pavilion tienen ahora, contamos con un sistema de gestión de plugins del que la CI es una parte. Así es como funciona
El cual muestra el estado de las comprobaciones de compatibilidad de los plugins de Pavilion (y a veces de otros) frente a tests-passed y stable. Esto se actualiza todos los días, automáticamente.
Esto, por supuesto, depende de las pruebas, incluidas las pruebas de humo, las especificaciones (backend) y las pruebas qunit (frontend).
Nuestro plugin de suscripción (Custom Wizard) tiene la mayor cobertura de pruebas, como te puedes imaginar, pero algunos de nuestros plugins gratuitos incluyen un buen conjunto de pruebas tanto de backend como de frontend (por ejemplo, Locations).
Escribir pruebas es una buena práctica y ciertamente Pavilion se ha vuelto aún más disciplinado en este espacio a medida que hemos madurado como negocio.
Críticamente, las pruebas también documentan la funcionalidad prevista, lo cual es extremadamente importante, especialmente durante las actualizaciones de compatibilidad o la refactorización.
Todos los plugins oficiales tienen especificaciones que puedes usar como ejemplos. El plugin discourse-plugin-Skelton incluye acciones de GitHub para ejecutar pruebas en cada commit, y creo, diariamente.
a) Esto está disponible a través de las acciones de GitHub: los plugins con especificaciones/pruebas adecuadas que utilizan las acciones de GitHub tendrán una insignia en GitHub, si todas las pruebas pasan y el estado de las acciones de CI es legible por la API.
b) Excepto los plugins oficiales de Discourse y los plugins de Pavilion, no existe una visión general automática para los administradores sobre si los plugins utilizados funcionarán en la versión prevista para la actualización.
Según entiendo, esta es una solución al problema inverso: Discourse demasiado antiguo para un plugin.
¿Cómo tratar el otro caso: plugin demasiado antiguo para Discourse?
¿Podría /admin/upgrade advertir sobre plugins que fallen las pruebas para una actualización prevista?
Originalmente nos propusimos y proporcionamos una versión sin marca de nuestro panel de plugins donde los autores de terceros podían presentar sus plugins para que se incluyeran. Esto no ganó tracción, en parte porque la población de desarrolladores de plugins de terceros es muy pequeña.
La creación de plugins de Discourse de terceros es bastante nicho y los terceros que proporcionan plugins con una buena cobertura de pruebas son muy nicho.
Muchos de los freelancers en este espacio se han unido a Pavilion o CDCK (¡o, con el tiempo, a ambos!).
Así que al final decidimos simplemente colapsar nuestro panel en nuestro sitio comunitario de marca.
