Le référentiel community-plugins est un endroit où les membres de la communauté peuvent héberger un plugin ou un ensemble de plugins. Le but des plugins communautaires est de réduire le nombre de pull request et de problèmes issus backstage/backstage , qui sont devenus trop importants avec le temps.
En créant des plugins communautaires, nous donnons aux responsables de plugins tous les outils pour gérer et publier facilement leurs plugins.
Les plugins créés par la communauté Backstage au sens large sont invités à être publiés dans le référentiel community-plugins . Lorsque vous contribuez à un plugin dans ce référentiel, vous acceptez de suivre des directives spécifiques, y compris un processus de publication standardisé. Cela permet aux propriétaires de plugins de tirer parti des processus établis et des connaissances collectives de la communauté community-plugins Backstage.
Pour ceux qui recherchent une autonomie totale sur le cycle de vie de développement et de publication de leur plugin, l'auto-hébergement reste une option prise en charge et valable. La décision de contribuer au référentiel communautaire ou de s'auto-héberger dépendra de si vous préférez gérer le développement du plugin de manière indépendante ou développer le plugin dans le cadre d'un processus piloté par la communauté. Les deux approches sont valorisées au sein de l’écosystème Backstage et contribuent à sa croissance.
Les plugins essentiels à la fonctionnalité et au fonctionnement de Backstage continueront de résider dans le référentiel backstage/backstage , garantissant ainsi que les composants centraux qui sous-tendent la plate-forme sont gérés et maintenus de manière centralisée.
Pour commencer à créer un nouveau plugin, suivez les instructions dans CONTRIBUTING.md.
Le référentiel community-plugins est constitué d'un ensemble d'espaces de travail. Un espace de travail contient un plugin ou un ensemble de plugins basés sur un sujet spécifique. Par exemple, le catalogue, Kubernetes et TechDocs peuvent être appelés espaces de travail.
Chaque plugin appartient à un espace de travail et les espaces de travail sont suffisamment portables pour être déplacés vers son propre référentiel si vous le souhaitez. Chaque espace de travail de plugin possède ses propres ensembles de modifications et versions isolées.
Les plugins dépendent d'autres plugins via des dépendances npm régulières, que les autres plugins soient des plugins principaux, d'autres plugins dans le référentiel ou des plugins externes.
Bien que le référentiel communautaire ne soit pas techniquement un espace de travail Yarn", il fonctionne comme un référentiel avec plusieurs espaces de travail Yarn, chaque espace de travail possédant son répertoire .changesets unique.
Chaque fois qu'un nouvel ensemble de modifications est introduit, un nouveau PR « Packages de version ($workspace_name) » est produit. La fusion d'un package de versions PR déclenchera la sortie de tous les plugins dans les espaces de travail (à condition que des ensembles de modifications aient été ajoutés) et mettra également à jour les fichiers CHANGELOG .
backstage/backstage Un certain nombre de plugins qui résidaient à l'origine dans le monorepo backstage/backstage ont été déplacés vers ce référentiel 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 migration des plugins du monorepo backstage/backstage vers le référentiel community-plugins a été automatisée sous l'outil community-cli .
Vous lui fournissez un chemin vers le monorepo qui doit être cloné localement et un ID de plugin. Il créera ensuite un nouvel espace de travail dans le référentiel community-plugins avec tous les plugins et modules qui entourent cet espace de travail. Par exemple, si j'utilise le plugin todo comme identifiant, il se déplacera automatiquement sur @backstage/plugin-todo ainsi que @backstage/plugin-todo-backend et tout autre -common , -node ou -modules liés.
Une fois le code copié, les étendues npm et toutes les références de code sont mises à jour pour refléter les nouvelles étendues de @backstage-community/plugin-* , et un ensemble de modifications est créé pour le package à publier. Les versions restent les mêmes pour le moment, mais l'ensemble de modifications résultant publiera la version suivante, donc si le package publié à 1.25.0 était 0.10.0 , alors la nouvelle version sera @backstage-community/plugin-todo 0.10.1 .
Un commit est créé dans le monorepo soit sur une branche spécifiée en tant que --branch soit sur une nouvelle branche créée pour la migration. Dans ce commit, il y a une dépréciation et un ensemble de modifications pour que ce package soit supprimé, donc 0.10.1 dans @backstage/plugin-todo sera marqué comme obsolète et remplacé par @backstage-community/plugin-todo comme la même version.
