El repositorio community-plugins es un lugar donde los miembros de la comunidad pueden alojar un complemento o un conjunto de complementos. El objetivo de los complementos comunitarios es reducir la cantidad de solicitudes de extracción y problemas entre backstage/backstage , que se han vuelto demasiado grandes con el tiempo.
Al crear complementos comunitarios, brindamos a los mantenedores de complementos todas las herramientas para administrar y publicar fácilmente sus complementos.
Los complementos creados por la comunidad Backstage en general pueden publicarse en el repositorio de community-plugins . Cuando contribuyes con un complemento a este repositorio, aceptas seguir pautas específicas, incluido un proceso de lanzamiento estandarizado. Esto permite a los propietarios de complementos aprovechar los procesos establecidos y el conocimiento colectivo de la comunidad community-plugins Backstage.
Para aquellos que buscan total autonomía sobre el desarrollo y el ciclo de vida de lanzamiento de su complemento, el autohospedaje sigue siendo una opción válida y compatible. La decisión de contribuir al repositorio de la comunidad o autohospedarlo dependerá de si prefiere administrar el desarrollo del complemento de forma independiente o desarrollar el complemento como parte de un proceso impulsado por la comunidad. Ambos enfoques son valorados dentro del ecosistema Backstage y contribuyen a su crecimiento.
Los complementos que son clave para la funcionalidad y el funcionamiento de Backstage seguirán residiendo en el repositorio backstage/backstage , lo que garantiza que los componentes centrales que sustentan la plataforma se gestionen y mantengan de forma centralizada.
Para comenzar a crear un nuevo complemento, siga las instrucciones en CONTRIBUTING.md.
El repositorio community-plugins está formado por un conjunto de espacios de trabajo. Un espacio de trabajo contiene un complemento o un conjunto de complementos basados en un tema específico. Por ejemplo, se puede hacer referencia a catálogo, kubernetes y TechDocs como espacios de trabajo.
Cada complemento pertenece a un espacio de trabajo y los espacios de trabajo son lo suficientemente portátiles como para moverlos a su propio repositorio si lo desea. Cada espacio de trabajo de complementos tiene sus propios conjuntos de cambios y versiones aisladas.
Los complementos dependen de otros complementos a través de dependencias regulares de npm, independientemente de si los otros complementos son complementos principales, otros complementos dentro del repositorio o complementos externos.
Aunque el repositorio de la comunidad no es técnicamente un espacio de trabajo de hilo, funciona como un repositorio con múltiples espacios de trabajo de hilo, y cada espacio de trabajo posee su directorio .changesets único.
Cada vez que se introduce un nuevo conjunto de cambios, se produce un nuevo PR "Paquetes de versión ($workspace_name)". La fusión de un paquete de versión PR activará el lanzamiento de todos los complementos en los espacios de trabajo (siempre que se hayan agregado conjuntos de cambios) y también actualizará los archivos CHANGELOG .
backstage/backstage Varios complementos que originalmente residían en backstage/backstage monorepo se han movido a este repositorio de backstage/community-plugins .
adrairbreakallureanalyticsapache-airflowapollo-explorerazure-devopsazure-sitesbadgesbazaarbitrisecicd-statisticscloudbuildcode-climatecode-coveragecodescenecost-insightsdynatraceentity-feedbackentity-validationexample-todo-listexplorefirehydrantfossagcalendargcp-projectsgit-release-managergithub-actionsgithub-deploymentsgithub-issuesgithub-pull-requests-boardgitops-profilesgocdgraphiqlgraphql-voyagerilertjenkinskafkalighthousemicrosoft-calendarnewrelicnewrelic-dashboardoctopus-deployopencostperiskopplaylistpuppetdbrollbarsentryshortcutssonarqubesplunkstack-overflowstackstormtech-insightstech-radartodovaultxcmetrics La migración de complementos desde backstage/backstage al repositorio community-plugins se automatizó con la herramienta community-cli .
Le proporciona una ruta al monorepo que debe clonarse localmente y una ID del complemento. Luego creará un nuevo espacio de trabajo en el repositorio community-plugins con todos los complementos y módulos que rodean ese espacio de trabajo. Por ejemplo, si uso el complemento todo como ID, se moverá automáticamente sobre @backstage/plugin-todo así como @backstage/plugin-todo-backend y cualquier otro -common , -node o -modules que esté relacionado.
Una vez que se copia el código, los alcances de npm y todas las referencias de código se actualizan para reflejar los nuevos alcances de @backstage-community/plugin-* y se crea un conjunto de cambios para el paquete que se publicará. Las versiones se mantienen iguales por ahora, pero el conjunto de cambios resultante publicará la siguiente versión, por lo que si el paquete lanzado en 1.25.0 era 0.10.0 , entonces la nueva versión será @backstage-community/plugin-todo 0.10.1 .
Hay una confirmación que se crea en monorepo en una rama especificada como --branch o en una nueva rama que se crea para la migración. En esta confirmación hay una desaprobación y un conjunto de cambios para que este paquete salga, por lo que 0.10.1 en @backstage/plugin-todo se marcará como obsoleto y se reemplazará con @backstage-community/plugin-todo como la misma versión.
