* Use a flag to determine wether to use techdocs-container or local install of mkdocs
* Updated techdocs generator to look at app-config string instead of argument to decide how to run the generator
* Removed console log...
* Reverted scaffolder file that was accidentally committed.
* Fixed lint issues
* Added config to create-app template
* new tutorial
* prettier formatting
* Update quickstart.md
* prettier write
* refined quickstart tutorial
* Create QuickStart-app-plugin
* Rename QuickStart-app-plugin to quickStart-app-plugin
* Update and rename quickStart-app-plugin to quickstart-app-plugin
* Adding second tutorial with prettier
* removing rogue file
* updating where to go link
* adding sidebars entry for new tutorials
We're deploying backstage to GKE and have had issues getting techdocs
volume mount logic to work because of mixing paths between the host and
the container running the backend. So we added a condition where if
mkdocs is found in the backend container it will use that to generate
the docs rather than spinning it up in a docker container.
Test for docker using ping() before attempting any docker
operations. If this fails we know docker is unavailable
and we can fail with an more descriptive error.
In my testing, attempts to create a docs site with no description would
fail with the error:
```
Unable to create file 'component-info.yaml'
Error message: 'collections.OrderedDict object' has no attribute 'description'
```
Better to mark it required than let the user hit the error.
This adds a GitLab integration for the scaffolder backend.
We're introduceing a preparer and a publisher for GitLab so that we can
read templates from GitLab and publish them to a configured GitLab
instance. The two instances don't need to be the same. For instance,
templates could be public on gitlab.com, but the created repos will live
in a hosted GitLab somewhere else.
The publisher gets its own config object in `app-config.yaml` where the
target instance and token can be specified.
The service catalogue defines both `gitlab` and `gitlab/api` as
processors. They are both handled by the same preparer.
Closes#2372
Tim Hansen