openslo / openslo-backstage-plugins Goto Github PK

The format for the repo name seems to match more what you'd expect for a repository that contains a single plugin. But since we are building a few closely related plugins and modules in a single repository, perhaps we should change the repository name sooner rather than later to reflect that.

And example of an existing plugin repo like this is https://github.com/RoadieHQ/roadie-backstage-plugins

Perhaps: openslo-backstage-plugins?

We could do this in one of three ways:

• Reference the web URL for the schema and have the plugin download it on demand
• Cache the JSON Schema in the plugin using a query as part of the build process
• A combination of the first two which falls back on the cached version when the web version is not accessible.

We want to setup our package.json to ensure that this single repo presents as multiple packages which can then be imported separately and all published to npm. Following the pattern of other existing backstage plugin repos with multiple packages.

Possible inspiration:

• https://github.com/backstage/backstage/tree/master/plugins
• https://stackoverflow.com/questions/45947998/multiple-npm-repos-in-one-github-repo-with-scoping

Once you have a common package in place you can start adding your own entity definitions. For the exact details on how to do that we defer to getting inspired by the existing scaffolder-common package. But in short you will need to declare a TypeScript type and a JSONSchema for the new entity kind.

Since the JSONSchema is not yet published to the web, we should probably use a git-submodule for the schema definition until that gets finished.

Once Backstage understands the OpenSLO format, we can create a simple set of React Components for displaying SLO information as a Card or Tab on a System that the SLO objects are attached to.

Using the openslo-common plugin, we need to write a custom backstage processor to have any OpenSLO documents found in catalog locations into the Catalog database:

https://backstage.io/docs/features/software-catalog/extending-the-model#building-a-custom-processor-for-the-entity

Taking inspiration from the https://github.com/backstage/backstage/tree/master/plugins structure, we want this repository to be home to multiple plugins:

• openslo-common
• openslo-backend
• openslo
• openslo-datasource-<name>

Backstage recommends to take plugin structure inspiration from: https://github.com/backstage/backstage/tree/master/plugins/scaffolder-common

Create a basic README describing:

• The purpose of the repository
• Each of the plugins
• Contribution
• Build & Deployment
• Testing

We should have github actions setup to publish the latest packages to NPM.

We probably want to have an OpenSLO npm account for this.

We need to setup CI actions to validate PRs prior to merging.

Some examples of initial checks that should be performed:

• linting
• unit-tests
• version reference checks (ensure versions are being incremented consistently)