Das community-plugins Repository ist ein Ort, an dem Mitglieder der Community ein Plugin oder eine Reihe von Plugins hosten können. Das Ziel von Community-Plugins besteht darin, die Menge an Pull-Requests und Issues aus backstage/backstage zu reduzieren, die mit der Zeit zu groß geworden sind.
Durch die Erstellung von Community-Plugins geben wir Plugin-Betreuern alle Tools an die Hand, mit denen sie ihre Plugins einfach verwalten und veröffentlichen können.
Plugins, die von der breiteren Backstage-Community erstellt wurden, können gerne im community-plugins Repository veröffentlicht werden. Wenn Sie ein Plugin zu diesem Repository beitragen, erklären Sie sich damit einverstanden, bestimmte Richtlinien zu befolgen, einschließlich eines standardisierten Veröffentlichungsprozesses. Dadurch können Plugin-Besitzer etablierte Prozesse und das kollektive Wissen der Backstage community-plugins Community nutzen.
Für diejenigen, die vollständige Autonomie über den Entwicklungs- und Veröffentlichungslebenszyklus ihres Plugins anstreben, bleibt Selbsthosting eine unterstützte und gültige Option. Die Entscheidung, entweder zum Community-Repository beizutragen oder sich selbst zu hosten, hängt davon ab, ob Sie die Entwicklung des Plugins lieber unabhängig verwalten oder das Plugin als Teil eines Community-gesteuerten Prozesses entwickeln möchten. Beide Ansätze werden im Backstage-Ökosystem geschätzt und tragen zu dessen Wachstum bei.
Plugins, die für die Funktionalität und den Betrieb von Backstage von entscheidender Bedeutung sind, verbleiben weiterhin im backstage/backstage Repository. Dadurch wird sichergestellt, dass die zentralen Komponenten, die der Plattform zugrunde liegen, zentral verwaltet und gewartet werden.
Um mit der Erstellung eines neuen Plugins zu beginnen, befolgen Sie die Anleitung in CONTRIBUTING.md.
Das community-plugins Repository besteht aus einer Reihe von Arbeitsbereichen. Ein Arbeitsbereich enthält ein Plugin oder eine Reihe von Plugins basierend auf einem bestimmten Thema. Beispielsweise können Katalog, Kubernetes und TechDocs als Arbeitsbereiche bezeichnet werden.
Jedes Plugin gehört zu einem Arbeitsbereich und Arbeitsbereiche sind portierbar genug, um bei Bedarf in ein eigenes Repository verschoben zu werden. Jeder Plugin-Arbeitsbereich verfügt über eigene Änderungssätze und isolierte Versionen.
Plugins sind über reguläre NPM-Abhängigkeiten von anderen Plugins abhängig, unabhängig davon, ob es sich bei den anderen Plugins um Kern-Plugins, andere Plugins innerhalb des Repositorys oder externe Plugins handelt.
Obwohl das Community-Repository technisch gesehen kein Garn-Arbeitsbereich ist, fungiert es als Repository mit mehreren Garn-Arbeitsbereichen, wobei jeder Arbeitsbereich sein eigenes .changesets -Verzeichnis besitzt.
Immer wenn ein neuer Änderungssatz eingeführt wird, wird eine neue PR „Versionspakete ($workspace_name)“ erstellt. Das Zusammenführen eines PR-Versionspakets löst die Veröffentlichung aller Plugins in den Arbeitsbereichen aus (sofern Änderungssätze hinzugefügt wurden) und aktualisiert auch die CHANGELOG Dateien.
backstage/backstage migriert Eine Reihe von Plugins, die sich ursprünglich im backstage/backstage Monorepo befanden, wurden in dieses backstage/community-plugins Repository verschoben.
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 Die Migration von Plugins vom backstage/backstage Monorepo zum community-plugins Repository wurde mit dem community-cli Tool automatisiert.
Sie geben einen Pfad zum monorepo an, das lokal geklont werden soll, und eine Plugin-ID. Anschließend wird im community-plugins Repository ein neuer Arbeitsbereich mit allen Plugins und Modulen erstellt, die diesen Arbeitsbereich umgeben. Wenn ich zum Beispiel das todo Plugin als ID verwende, wird es automatisch über @backstage/plugin-todo sowie @backstage/plugin-todo-backend und alle anderen zugehörigen -common , -node oder -modules verschoben.
Sobald der Code kopiert wurde, werden die npm-Bereiche und alle Codeverweise aktualisiert, um die neuen Bereiche von @backstage-community/plugin-* widerzuspiegeln, und es wird ein Änderungssatz für das zu veröffentlichende Paket erstellt. Die Versionen bleiben vorerst gleich, aber der resultierende Änderungssatz wird die nächste Version veröffentlichen. Wenn also das mit 1.25.0 veröffentlichte Paket 0.10.0 war, dann wird die neue Version @backstage-community/plugin-todo 0.10.1 sein .
Es gibt einen Commit, der im monorepo entweder für einen angegebenen Zweig als --branch oder für einen neuen Zweig erstellt wird, der für die Migration erstellt wird. In diesem Commit ist eine Verwerfung und ein Changeset für dieses Paket enthalten, sodass 0.10.1 in @backstage/plugin-todo als veraltet markiert und durch @backstage-community/plugin-todo als dieselbe Version ersetzt wird.
