O repositório community-plugins é um local onde os membros da comunidade podem hospedar um plugin ou um conjunto de plugins. O objetivo dos plugins comunitários é reduzir a quantidade de pull requests e problemas de backstage/backstage , que se tornou muito grande com o tempo.
Ao criar plugins comunitários, damos aos mantenedores de plugins todas as ferramentas para gerenciar e publicar facilmente seus plugins.
Plugins criados pela comunidade Backstage mais ampla podem ser publicados no repositório community-plugins . Ao contribuir com um plugin para este repositório, você concorda em seguir diretrizes específicas, incluindo um processo de lançamento padronizado. Isso permite que os proprietários de plug-ins aproveitem os processos estabelecidos e o conhecimento coletivo da comunidade community-plugins Backstage.
Para aqueles que buscam total autonomia sobre o ciclo de vida de desenvolvimento e lançamento de seu plugin, a auto-hospedagem continua sendo uma opção válida e suportada. A decisão de contribuir para o repositório da comunidade ou auto-hospedar dependerá se você prefere gerenciar o desenvolvimento do plugin de forma independente ou desenvolver o plugin como parte de um processo conduzido pela comunidade. Ambas as abordagens são valorizadas dentro do ecossistema Backstage e contribuem para o seu crescimento.
Os plug-ins essenciais para a funcionalidade e operação do Backstage continuarão a residir no repositório backstage/backstage – garantindo que os componentes centrais que sustentam a plataforma sejam gerenciados e mantidos centralmente.
Para começar a criar um novo plugin, siga as orientações em CONTRIBUTING.md.
O repositório community-plugins é formado por um conjunto de espaços de trabalho. Um espaço de trabalho contém um plugin ou um conjunto de plugins baseados em um tópico específico. Por exemplo, catálogo, kubernetes e TechDocs podem ser chamados de espaços de trabalho.
Cada plugin pertence a um espaço de trabalho e os espaços de trabalho são portáteis o suficiente para serem movidos para seu próprio repositório, se desejado. Cada espaço de trabalho de plugin tem seus próprios conjuntos de alterações e versões isoladas.
Os plug-ins dependem de outros plug-ins por meio de dependências npm regulares, independentemente de os outros plug-ins serem plug-ins principais, outros plug-ins dentro do repositório ou plug-ins externos.
Embora o repositório da comunidade não seja tecnicamente um espaço de trabalho do Yarn", ele funciona como um repositório com vários espaços de trabalho do Yarn, com cada espaço de trabalho possuindo seu diretório .changesets exclusivo.
Sempre que um novo conjunto de alterações é introduzido, um novo PR "Pacotes de versão ($workspace_name)" é produzido. A mesclagem de pacotes de versão PR acionará o lançamento de todos os plug-ins nos espaços de trabalho (desde que os conjuntos de alterações tenham sido adicionados) e também atualizará os arquivos CHANGELOG .
backstage/backstage Vários plug-ins que originalmente residiam no backstage/backstage monorepo foram movidos para este repositório 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 A migração de plugins do backstage/backstage monorepo para o repositório community-plugins foi automatizada na ferramenta community-cli .
Você fornece um caminho para o monorepo que deve ser clonado localmente e um ID do plugin. Em seguida, ele criará um novo espaço de trabalho no repositório community-plugins com todos os plugins e módulos que cercam esse espaço de trabalho. Por exemplo, se eu usar o plugin todo como um ID, ele passará automaticamente para @backstage/plugin-todo bem como @backstage/plugin-todo-backend e qualquer outro -common , -node ou -modules que estejam relacionados.
Depois que o código é copiado, os escopos npm e todas as referências de código são atualizados para refletir os novos escopos de @backstage-community/plugin-* e um conjunto de alterações é criado para o pacote a ser publicado. As versões são mantidas as mesmas por enquanto, mas o conjunto de alterações resultante publicará a próxima versão, portanto, se o pacote lançado em 1.25.0 for 0.10.0 , a nova versão será @backstage-community/plugin-todo 0.10.1 .
Há um commit criado no monorepo em uma ramificação especificada como --branch ou em uma nova ramificação criada para a migração. Neste commit há uma descontinuação e um conjunto de alterações para este pacote ser lançado, então 0.10.1 em @backstage/plugin-todo será marcado como obsoleto e substituído por @backstage-community/plugin-todo como a mesma versão.
