base on Community plugins for Backstage # Backstage Community Plugins [](https://opensource.org/licenses/Apache-2.0) [](https://www.cncf.io/projects) [](https://discord.gg/backstage-687207715902193673) ## What is the community-plugins repository? The `community-plugins` repository is a place where members of the community can host a plugin or a set of plugins. The goal of community-plugins is to reduce the amount of pull requests and issues from `backstage/backstage`, which has become too big with the time. By creating community-plugins we give to plugin maintainers all the tools to easily manage and publish their plugins. ## Contributing a plugin Plugins created by the wider Backstage community are welcome to be published in the `community-plugins` repository. When you contribute a plugin to this repository, you agree to follow specific guidelines, including a standardized release process. This allows plugin owners to leverage established processes and the collective knowledge of the Backstage `community-plugins` community. For those seeking full autonomy over their plugin's development and release lifecycle, self-hosting remains a supported and valid option. The decision to either contribute to the community repository or self-host will depend on whether you prefer to manage the development of the plugin independently or develop the plugin as part of a community-driven process. Both approaches are valued within the Backstage ecosystem and contribute to its growth. Plugins that are key to the functionality and operation of Backstage will continue to reside in the `backstage/backstage` repository - ensuring the central components that underpin the platform are centrally managed and maintained. To get started with creating a new plugin, follow the guidance in [CONTRIBUTING.md](https://github.com/backstage/community-plugins/blob/main/CONTRIBUTING.md#creating-a-new-workspace). ## Community Plugins Workflow The `community-plugins` repository is formed by a set of workspaces. A workspace holds a plugin or a set of plugins based on a specific topic. For example, catalog, kubernetes, and TechDocs can be referred to as workspaces. Each plugin belongs to a workspace and workspaces are portable enough to be moved to its own repository if desired. Each plugin workspace has its own changesets and isolated releases. Plugins depend on other plugins via regular npm dependencies, regardless of whether the other plugins are core plugins, other plugins within the repository, or external plugins. Although the community repository isn't technically a yarn workspace", it functions as a repository with multiple yarn workspaces, with each workspace possessing its unique `.changesets` directory. Whenever a new changeset is introduced, a fresh "Version packages ($workspace_name)" PR is produced. Merging a Version packages PR will trigger the release of all the plugins in the workspaces (provided changesets have been added), and also update the `CHANGELOG` files. ## Plugins migrated from `backstage/backstage` A number of plugins that originally resided in `backstage/backstage` monorepo have moved to this `backstage/community-plugins` repository. <details> <summary>List of migrated plugins</summary> - `adr` - `airbreak` - `allure` - `analytics` - `apache-airflow` - `apollo-explorer` - `azure-devops` - `azure-sites` - `badges` - `bazaar` - `bitrise` - `cicd-statistics` - `cloudbuild` - `code-climate` - `code-coverage` - `codescene` - `cost-insights` - `dynatrace` - `entity-feedback` - `entity-validation` - `example-todo-list` - `explore` - `firehydrant` - `fossa` - `gcalendar` - `gcp-projects` - `git-release-manager` - `github-actions` - `github-deployments` - `github-issues` - `github-pull-requests-board` - `gitops-profiles` - `gocd` - `graphiql` - `graphql-voyager` - `ilert` - `jenkins` - `kafka` - `lighthouse` - `microsoft-calendar` - `newrelic` - `newrelic-dashboard` - `octopus-deploy` - `opencost` - `periskop` - `playlist` - `puppetdb` - `rollbar` - `sentry` - `shortcuts` - `sonarqube` - `splunk` - `stack-overflow` - `stackstorm` - `tech-insights` - `tech-radar` - `todo` - `vault` - `xcmetrics` </details> ### Migration process The migration of plugins from the `backstage/backstage` monorepo to the `community-plugins` repository was automated under the `community-cli` tool. You provide it with a path to the `monorepo` which should be cloned locally, and a plugin ID. It will then create a new workspace in the `community-plugins` repository with all of the plugins and modules that surround that workspace. For instance, if I use the `todo` plugin as an ID, It will automatically move over `@backstage/plugin-todo` as well as `@backstage/plugin-todo-backend` and any other `-common`, `-node` or `-modules` that are related. Once the code is copied over, the npm scopes and all code references are updated to reflect the new scopes of `@backstage-community/plugin-*`, and a changeset is created for the package to be published. The versions are kept the same for now, but the resulting changeset will publish the next version along, so if the package released at `1.25.0` was `0.10.0` then the new version will be `@backstage-community/plugin-todo` `0.10.1`. There is a commit that is created in the `monorepo` on either a specified branch as `--branch` or on a new branch that is created for the migration. In this commit is a deprecation and a changeset for this package to go out, so `0.10.1` in `@backstage/plugin-todo` will be marked as deprecated and replaced with `@backstage-community/plugin-todo` as the same version. ", Assign "at most 3 tags" to the expected json: {"id":"9664","tags":[]} "only from the tags list I provide: [{"id":77,"name":"3d"},{"id":89,"name":"agent"},{"id":17,"name":"ai"},{"id":54,"name":"algorithm"},{"id":24,"name":"api"},{"id":44,"name":"authentication"},{"id":3,"name":"aws"},{"id":27,"name":"backend"},{"id":60,"name":"benchmark"},{"id":72,"name":"best-practices"},{"id":39,"name":"bitcoin"},{"id":37,"name":"blockchain"},{"id":1,"name":"blog"},{"id":45,"name":"bundler"},{"id":58,"name":"cache"},{"id":21,"name":"chat"},{"id":49,"name":"cicd"},{"id":4,"name":"cli"},{"id":64,"name":"cloud-native"},{"id":48,"name":"cms"},{"id":61,"name":"compiler"},{"id":68,"name":"containerization"},{"id":92,"name":"crm"},{"id":34,"name":"data"},{"id":47,"name":"database"},{"id":8,"name":"declarative-gui "},{"id":9,"name":"deploy-tool"},{"id":53,"name":"desktop-app"},{"id":6,"name":"dev-exp-lib"},{"id":59,"name":"dev-tool"},{"id":13,"name":"ecommerce"},{"id":26,"name":"editor"},{"id":66,"name":"emulator"},{"id":62,"name":"filesystem"},{"id":80,"name":"finance"},{"id":15,"name":"firmware"},{"id":73,"name":"for-fun"},{"id":2,"name":"framework"},{"id":11,"name":"frontend"},{"id":22,"name":"game"},{"id":81,"name":"game-engine "},{"id":23,"name":"graphql"},{"id":84,"name":"gui"},{"id":91,"name":"http"},{"id":5,"name":"http-client"},{"id":51,"name":"iac"},{"id":30,"name":"ide"},{"id":78,"name":"iot"},{"id":40,"name":"json"},{"id":83,"name":"julian"},{"id":38,"name":"k8s"},{"id":31,"name":"language"},{"id":10,"name":"learning-resource"},{"id":33,"name":"lib"},{"id":41,"name":"linter"},{"id":28,"name":"lms"},{"id":16,"name":"logging"},{"id":76,"name":"low-code"},{"id":90,"name":"message-queue"},{"id":42,"name":"mobile-app"},{"id":18,"name":"monitoring"},{"id":36,"name":"networking"},{"id":7,"name":"node-version"},{"id":55,"name":"nosql"},{"id":57,"name":"observability"},{"id":46,"name":"orm"},{"id":52,"name":"os"},{"id":14,"name":"parser"},{"id":74,"name":"react"},{"id":82,"name":"real-time"},{"id":56,"name":"robot"},{"id":65,"name":"runtime"},{"id":32,"name":"sdk"},{"id":71,"name":"search"},{"id":63,"name":"secrets"},{"id":25,"name":"security"},{"id":85,"name":"server"},{"id":86,"name":"serverless"},{"id":70,"name":"storage"},{"id":75,"name":"system-design"},{"id":79,"name":"terminal"},{"id":29,"name":"testing"},{"id":12,"name":"ui"},{"id":50,"name":"ux"},{"id":88,"name":"video"},{"id":20,"name":"web-app"},{"id":35,"name":"web-server"},{"id":43,"name":"webassembly"},{"id":69,"name":"workflow"},{"id":87,"name":"yaml"}]" returns me the "expected json"