* Add TechdocsMetadata type in backend plugin endpoint
* Introduce TechDocsMetadata type in frontend
* Add changeset
* Remove old thennable metadata resp
* Address PR feedback
- Remove explicit type annotation on TechDocsMetadata
- Reintroduce res.send instead of throwing an error
- Change logger info to logger error
* Add TechDocsMetadata type in frontend plugin
* Commit yarn.lock
* Introduce JSON5 and remove parsing in local pub
Signed-off-by: Matei David <matei.david.35@gmail.com>
It is time to start using URL Reader for the exmaple docs components we provide in the out-of-the-box experience (i.e. when users experience TechDocs by doing a git clone of this repository).
URL Reader makes the prepare step 8x faster.
This caching makes it usable experience, so that docs are not built on every load.
In future readTree will support a method to fetch the timestamp of the latest HEAD. And
it should be used to invalidate the cache.
The creation of temporary directories and their clean up should be handled on its own. techdocs-cli already has a fixed input output dir requirement. It makes that generator accepts these values as requirements.
When a new Backstage app is setup, the techdocs backend file contains all the preparers (dir, github, gitlab, etc.) and same for generators. While this providers added customizibility, it comes with a cost of complexity in setting up the app backend. New preparers' updates would need users to update their app's techdocs backend file.
Scaffolder backend has already moved to this proposed pattern.
Pasting a URL like `https://github.com/RoadieHQ/sample-service/blob/master/catalog-info-1.yaml`
into the Register Existing Component input creates an Entity with the
the `backstage.io/managed-by-location` annotation set to the `type` of
`url.
The TechDocs perparer does not handle this type.
```ts
switch (type) {
case 'github':
case 'gitlab':
case 'azure/api': {
// ...
}
case 'file':
// ...
default:
throw new InputError(`Unable to resolve location type ${type}`);
}
}
```
Thus, docs are never generated and we see the following error when
trying to view then in Backstage.
```
InputError: Unable to resolve location type url at DirectoryPreparer.resolveManagedByLocationToDir (webpack-internal:///../../node_modules/@backstage/plugin-techdocs-backend/src/techdocs/stages/prepare/dir.ts:63:15) at DirectoryPreparer.prepare (webpack-internal:///../../node_modules/@backstage/plugin-techdocs-backend/src/techdocs/stages/prepare/dir.ts:73:51) at DocsBuilder.build (webpack-internal:///../../node_modules/@backstage/plugin-techdocs-backend/src/service/helpers.ts:74:45) at eval (webpack-internal:///../../node_modules/@backstage/plugin-techdocs-backend/src/service/router.ts:141:25) at processTicksAndRejections (internal/process/task_queues.js:93:5)
```
This may not be the correct solution. An alternative solution would be
to ensure that pasted URLs end up with the `type` of `github` rather
than `url`.
Plus
1. Introduce ncessary configs to connect with storage
2. Introduce config to prefer CI build of docs, or techdocs-backend to build and publish them.
3. Write guide how to use Google Cloud Storage with TechDocs
4. Add a TechDocs Configuration reference page in docucmentation
If a backstage App wants to enable techdocs plugin, it should only have to care about installing @backstage/plugin-techdocs and @backstage/plugin-techdocs-backend.
@backstage/plugin-techdocs-backend should re-export necessary APIs from techdocs-common
github-actions[bot]