Solve the long lived branch problem for the backstage plugin

Since the current https://github.com/kiegroup/backstage-plugins is a fork of https://github.com/janus-idp/backstage-plugins, we need to have a long lived proprietary branch with our changes that will be constantly rebased against the upstream janus-idp.

Since every PR against janus-idp (including ours) will change the yarn.lock file, as there's a husky script that will run yarn install every git command, and since the yarn.lock file is committed inside the janus-idp repository, this will generate many.

While creating PR against the janus-idp repository consists of usually one conflict each PR, keeping a long lived branch without merging means that we'll have a number of conflicts increasing every new PR, because it will be the current PR being merged conflicting and all the previous PRs that were never merged inside Janus IDP repository.

Currently I see two solutions:

Develop scorecards inside this repository https://github.com/backstage/community-plugins - this has a different yarn.lock file for each different plugin so it should never conflict.
Host the backstage plugin inside the https://github.com/kiegroup/akrivis repository. This solution is described in the previous repository as well https://github.com/backstage/community-plugins#contributing-a-plugin

"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."

But no instructions are given on how to self host a backstage plugin.

kiegroup / akrivis

Solve the long lived branch problem for the backstage plugin #11