Backstage - release-2021-07-14.1

Extract an entity-oriented Jenkins Backend

Originally, the jenkins plugin was frontend-only. This PR extracts a separate backend plugin with an entity-oriented API which allows the creation of a jenkins-backend plugin which provides a hook to allow Integrators to customise how jenkins instances (and the jobs for entities) are discovered.

Examples are provided and documented in the backend plugin readme

This was mainly done to focus discussion on https://github.com/backstage/backstage/issues/5518 but may also prove to be an alternative to https://github.com/backstage/backstage/pull/5016

An entity has an array of associated projects each of which has a number of builds. This is a filtered and augmented view of the upstream jenkins project and build models. This model is used as the response objects from the API but also throughout the UI.

Apart from moving some functionality into the backend, the intermediate model CITableBuildInfo (which represented a build with some project info) has been removed in favour of using Project and Build throughout.

TODO

• [x] Support retry
• [x] Add changesets
• Route change for specific builds
• New backend plugin needed (incl. config)
• New annotation name and possible values
• [x] Remove all ts-ignore
• [x] config schema
• [ ] Render errors (particularly from invalid config) in UI
• [x] update microsite
• [ ] tests

There are some more refactoring / improvement which could be done but I'm not sure if including it here would make this PR too complicated.

• rename useBuilds hook to useProjects, useBuildWithSteps to useBuild and generally make sure we are consistent with jenkins terminology
• Support an entity having multiple associated jenkins jobs
• In router.ts and internal backend APIs generally
• in DefaultJenkinsInfoProvider
• Support more possible jenkins layouts (in both the code in router.ts and the UI)
• Move off of the jenkins client library and just use direct REST calls.
• The client library is <1.0 and the typings are out of date
• How do we generically reference a specific project. Currently this is entity + jobName but that doesn't scale to allow an entity to have jobs on multiple jenkins instances (build + deploy for example)

Questions

• The documentation feels a bit split across the READMEs in frontend and backend plugin, would it be better merged into one place
• I have change the id of the jenkinsApiRef. Is this needed as this is only used in the frontend plugin itself so doesn't need to be versioned particularly.
• I have included support for a simpler configuration scheme if you only have 1 instance (jenkins.baseUrl) and have described it as "deprecated" which I don't think is right as we only introduced it in this PR! How do we feel about the simplest possible config being:

jenkins:
  instances:
    - name: default
      baseUrl: https://jenkins.example.com
      username: backstage-bot
      apiKey: 123456789abcdef0123456789abcedf012

instead of:

jenkins:
  baseUrl: https://jenkins.example.com
  username: backstage-bot
  apiKey: 123456789abcdef0123456789abcedf012

The latter is more expressive but adds complexity in having to explain 2 config layouts. * Is the route change in the UI too big a change? * Should the frontend plugin expost an API for extensibility or is the backend ones enough?

closes #5016 #5518