Merge pull request #8 from spotify/master

Update Fork

.eslintignore

@@ -7,3 +7,5 @@
 **/.git/**
 **/public/**
 **/microsite/**
+**/templates/**
+**/sample-templates/**

.github/workflows/e2e.yml

@@ -3,6 +3,8 @@ name: E2E Test Linux
 on:
   pull_request:
     paths-ignore:
+      - 'contrib/**'
+      - 'docs/**'
       - 'microsite/**'
 
 jobs:

CHANGELOG.md

@@ -6,13 +6,15 @@ If you encounter issues while upgrading to a newer version, don't hesitate to re
 
 ## Next Release
 
+> Collect changes for the next release below
+
+## v0.1.1-alpha.22
+
 ### @backstage/core
 
 - Introduced initial version of an inverted app/plugin relationship, where plugins export components for apps to use, instead registering themselves directly into the app. This enables more fine-grained control of plugin features, and also composition of plugins such as catalog pages with additional cards and tabs. This breaks the use of `RouteRef`s, and there will be more changes related to this in the future, but this change lays the initial foundation. See `packages/app` and followup PRs for how to update plugins for this change. [#2076](https://github.com/spotify/backstage/pull/2076)
 - Switch to an automatic dependency injection mechanism for all Utility APIs, allowing plugins to ship default implementations of their APIs. See [https://backstage.io/docs/api/utility-apis](https://backstage.io/docs/api/utility-apis). [#2285](https://github.com/spotify/backstage/pull/2285)
 
-> Collect changes for the next release below
-
 ### @backstage/cli
 
 - Change `backstage-cli backend:build-image` to forward all args to `docker image build`, instead of just tag. Also add `--build` flag for building all dependent packages before packaging the workspace for the docker build. [#2299](https://github.com/spotify/backstage/pull/2299)
@@ -21,6 +23,10 @@ If you encounter issues while upgrading to a newer version, don't hesitate to re
 
 - Change root `tsc` output dir to `dist-types`, in order to allow for standalone plugin repos. [#2278](https://github.com/spotify/backstage/pull/2278)
 
+### @backstage/catalog-backend
+
+- We have simplified the way that GitHub ingestion works. The `catalog.processors.githubApi` key is deprecated, in favor of `catalog.processors.github`. At the same time, the location type `github/api` is likewise deprecated, in favor of `github`. This location type now serves both raw HTTP reads and APIv3 reads, depending on how you configure it. It also supports having several providers at once - for example, both public GitHub and an internal GitHub Enterprise, with different keys. If you still use the `catalog.processors.githubApi` config key, things will work but you will get a deprecation warning at startup. In a later release, support for the old key will go away entirely. See the [configuration section in the docs](https://backstage.io/docs/features/software-catalog/configuration) for more details.
+
 ## v0.1.1-alpha.21
 
 - Added many more frontend plugins to the template along with the sidebar. [#1942](https://github.com/spotify/backstage/pull/1942), [#2084](https://github.com/spotify/backstage/pull/2084)

app-config.yaml

@@ -35,6 +35,8 @@ organization:
 techdocs:
   storageUrl: http://localhost:7000/techdocs/static/docs
   requestUrl: http://localhost:7000/techdocs/docs
+  generators:
+    techdocs: 'docker'
 
 sentry:
   organization: spotify
@@ -57,10 +59,24 @@ catalog:
   rules:
     - allow: [Component, API, Group, Template, Location]
   processors:
-    githubApi:
-      privateToken:
-        $secret:
-          env: GITHUB_PRIVATE_TOKEN
+    github:
+      providers:
+        - target: https://github.com
+          token:
+            $secret:
+              env: GITHUB_PRIVATE_TOKEN
+        #### Example for how to add your GitHub Enterprise instance using the API:
+        # - target: https://ghe.example.net
+        #   apiBaseUrl: https://ghe.example.net/api/v3
+        #   token:
+        #     $secret:
+        #       env: GHE_PRIVATE_TOKEN
+        #### Example for how to add your GitHub Enterprise instance using raw HTTP fetches (token is optional):
+        # - target: https://ghe.example.net
+        #   rawBaseUrl: https://ghe.example.net/raw
+        #   token:
+        #     $secret:
+        #       env: GHE_PRIVATE_TOKEN
     bitbucketApi:
       username:
         $secret:
@@ -98,6 +114,19 @@ catalog:
     - type: github
       target: https://github.com/spotify/backstage/blob/master/plugins/scaffolder-backend/sample-templates/all-templates.yaml
 
+scaffolder:
+  github:
+    token:
+      $secret:
+        env: GITHUB_ACCESS_TOKEN
+    visibility: public # or 'internal' or 'private'
+  gitlab:
+    api:
+      baseUrl: https://gitlab.com
+      token:
+        $secret:
+          env: GITLAB_ACCESS_TOKEN
+
 auth:
   providers:
     google:

contrib/README.md

@@ -0,0 +1,9 @@
+# Backstage Contrib
+
+This directory contains various community contributions related to Backstage.
+
+Unless otherwise specified, all content in this hierarchy fall under the same
+[licensing terms](../LICENSE) as in the rest of the repository, and come with
+no guarantees of functionality or fitness of purpose. That being said, we
+really appreciate contributions in here and encourage them being kept up to
+date.

contrib/docker/multi-stage-frontend/Dockerfile

@@ -0,0 +1,23 @@
+FROM node:12 AS build
+
+RUN mkdir /app
+COPY . /app
+WORKDIR /app
+
+RUN yarn install
+RUN yarn workspace example-app build
+
+# Contruct backstage-frontend image
+FROM nginx:mainline
+
+RUN apt-get update && apt-get -y install jq && rm -rf /var/lib/apt/lists/*
+
+# Copy from build stage
+COPY --from=build /app/packages/app/dist /usr/share/nginx/html
+
+COPY docker/default.conf.template /etc/nginx/conf.d/default.conf.template
+COPY docker/run.sh /usr/local/bin/run.sh
+
+CMD run.sh
+
+ENV PORT 80

contrib/docker/multi-stage-frontend/README.md

@@ -0,0 +1,19 @@
+# Standalone Dockerfile for frontend
+
+This directory contains the resources which will help you build backstage without any requirements
+other than docker itself. It uses a multi-stage Dockerfile to build and ship backstage.
+
+## Usage
+
+You can simply run the following command to build backstage.
+
+```
+# Make sure you are in the root directory of backstage then run
+docker build -t backstage-frontend -f ./contrib/docker/multi-stage-frontend/Dockerfile .
+```
+
+After a successful build, You can simply run backstage frontend with the following command.
+
+```
+docker run -it --rm -p 3080:80 backstage-frontend
+```

contrib/kubernetes/basic_kubernetes_example_with_helm/README.md

@@ -0,0 +1 @@
+# Basic Kubernetes example with Helm

docs/FAQ.md

@@ -1,6 +1,7 @@
 ---
 id: FAQ
 title: FAQ
+description: All FAQ related to Backstage
 ---
 
 ## Product FAQ

docs/api/backend.md

@@ -1,6 +1,7 @@
 ---
 id: backend
 title: Backend
+description: About Backend
 ---
 
 ## TODO

docs/api/utility-apis.md

@@ -1,6 +1,7 @@
 ---
 id: utility-apis
 title: Utility APIs
+description: Backstage Utility APIs
 ---
 
 ## Introduction

docs/architecture-decisions/adr001-add-adr-log.md

@@ -1,7 +1,7 @@
 ---
 id: adrs-adr001
 title: ADR001: Architecture Decision Record (ADR) log
-sidebar_label: ADR001
+description: Architecture Decision Record (ADR) logs as a reference point for the team
 ---
 
 | Created    | Status |

docs/architecture-decisions/adr002-default-catalog-file-format.md

@@ -1,7 +1,7 @@
 ---
 id: adrs-adr002
 title: ADR002: Default Software Catalog File Format
-sidebar_label: ADR002
+description: Architecture Decision Record (ADR) log on Default Software Catalog File Format
 ---
 
 | Created    | Status |

docs/architecture-decisions/adr003-avoid-default-exports.md

@@ -1,7 +1,7 @@
 ---
 id: adrs-adr003
 title: ADR003: Avoid Default Exports and Prefer Named Exports
-sidebar_label: ADR003
+description: Architecture Decision Record (ADR) log on Avoid Default Exports and Prefer Named Exports
 ---
 
 | Created    | Status |

docs/architecture-decisions/adr004-module-export-structure.md

@@ -1,7 +1,7 @@
 ---
 id: adrs-adr004
 title: ADR004: Module Export Structure
-sidebar_label: ADR004
+description: Architecture Decision Record (ADR) log on Module Export Structure
 ---
 
 | Created    | Status |

docs/architecture-decisions/adr005-catalog-core-entities.md

@@ -1,7 +1,7 @@
 ---
 id: adrs-adr005
 title: ADR005: Catalog Core Entities
-sidebar_label: ADR005
+description: Architecture Decision Record (ADR) log on Catalog Core Entities
 ---
 
 | Created    | Status |

docs/architecture-decisions/adr006-avoid-react-fc.md

@@ -1,7 +1,7 @@
 ---
 id: adrs-adr006
 title: ADR006: Avoid React.FC and React.SFC
-sidebar_label: ADR006
+description: Architecture Decision Record (ADR) log on Avoid React.FC and React.SFC
 ---
 
 ## Context

docs/architecture-decisions/adr007-use-msw-to-mock-service-requests.md

@@ -1,7 +1,7 @@
 ---
 id: adrs-adr007
 title: ADR007: Use MSW to mock http requests
-sidebar_label: ADR007
+description: Architecture Decision Record (ADR) log on Use MSW to mock http requests
 ---
 
 ## Context

docs/architecture-decisions/adr008-default-catalog-file-name.md

@@ -1,7 +1,7 @@
 ---
 id: adrs-adr008
 title: ADR008: Default Catalog File Name
-sidebar_label: ADR008
+description: Architecture Decision Record (ADR) log on Default Catalog File Name
 ---
 
 ## Background

docs/architecture-decisions/index.md

@@ -2,6 +2,7 @@
 id: adrs-overview
 title: Architecture Decision Records (ADR)
 sidebar_label: Overview
+description: Overview of Architecture Decision Records (ADR)
 ---
 
 The substantial architecture decisions made in the Backstage project live here.

docs/auth/add-auth-provider.md

@@ -1,6 +1,7 @@
 ---
 id: add-auth-provider
 title: Adding authentication providers
+description: Documentation on Adding authentication providers
 ---
 
 ## Passport

docs/auth/auth-backend-classes.md

@@ -1,6 +1,7 @@
 ---
 id: auth-backend-classes
 title: Auth backend classes
+description: Documentation on Auth backend classes
 ---
 
 ## How Does Authentication Work?

docs/auth/auth-backend.md

@@ -1,6 +1,7 @@
 ---
 id: auth-backend
 title: Auth backend
+description: Documentation on Auth backend
 ---
 
 ## TODO

docs/auth/glossary.md

@@ -1,6 +1,7 @@
 ---
 id: glossary
 title: Glossary
+description: All Glossaries related to auth
 ---
 
 - **Popup** - A separate browser window opened on top of the previous one.

docs/auth/index.md

@@ -1,6 +1,7 @@
 ---
 id: index
 title: User Authentication and Authorization in Backstage
+description: Documentation on User Authentication and Authorization in Backstage
 ---
 
 ## Summary

docs/auth/oauth.md

@@ -1,6 +1,9 @@
 ---
 id: oauth
 title: OAuth and OpenID Connect
+description: This section describes how Backstage allows plugins to request
+OAuth Access Tokens and OpenID Connect ID Tokens on behalf of the user, to be
+used for auth to various third party APIs
 ---
 
 This section describes how Backstage allows plugins to request OAuth Access
@@ -104,10 +107,10 @@ request an access token.
 
 The following diagram visualizes the flow described in the previous section.
 
-![](oauth-popup-flow.svg)
+![Sequence Diagram](../assets/auth/oauth-popup-flow.svg)
 
 <!--
-@startuml oauth-popup-flow
+@startuml /../assets/auth/oauth-popup-flow
 
 skinparam monochrome true
 skinparam shadowing false

docs/conf/defining.md

@@ -1,6 +1,7 @@
 ---
 id: defining
 title: Defining Configuration for your Plugin
+description: Documentation on Defining Configuration for your Plugin
 ---
 
 There is currently no tooling support or helpers for defining plugin

docs/conf/index.md

@@ -1,6 +1,7 @@
 ---
 id: index
 title: Static Configuration in Backstage
+description: Documentation on Static Configuration in Backstage
 ---
 
 ## Summary

docs/conf/reading.md

@@ -1,6 +1,7 @@
 ---
 id: reading
 title: Reading Backstage Configuration
+description: Documentation on Reading Backstage Configuration
 ---
 
 ## Config API

docs/conf/writing.md

@@ -1,6 +1,7 @@
 ---
 id: writing
 title: Writing Backstage Configuration Files
+description: Documentation on Writing Backstage Configuration Files
 ---
 
 ## File Format

docs/dls/contributing-to-storybook.md

@@ -1,6 +1,7 @@
 ---
 id: contributing-to-storybook
 title: Contributing to Storybook
+description: Documentation on How to Contribute to Storybook
 ---
 
 You find our storybook at

docs/dls/design.md

@@ -1,6 +1,7 @@
 ---
 id: design
 title: Design
+description: Documentation on Design
 ---
 
 ![header](../assets/dls/designheader-updated.png)

docs/dls/figma.md

@@ -1,6 +1,8 @@
 ---
 id: figma
 title: Figma
+description: Documentation on using Figma to build your own plugins for
+Backstage
 ---
 
 We have a [Figma component library](https://www.figma.com/@backstage) that you

docs/features/software-catalog/api.md

@@ -1,6 +1,7 @@
 ---
 id: software-catalog-api
 title: API
+description: Documentation on Software Catalog API
 ---
 
 ## TODO

docs/features/software-catalog/configuration.md

@@ -1,8 +1,70 @@
 ---
 id: software-catalog-configuration
 title: Catalog Configuration
+description: Documentation on Software Catalog Configuration
 ---
 
+## Processors
+
+The catalog makes use of so called processors to perform all kinds of ingestion
+tasks, such as reading raw entity data from a remote source, parsing it,
+transforming it, and validating it. These processors are configured under the
+`catalog.processors` key.
+
+### Processor: github
+
+The `github` processor is responsible for fetching entity data from files on
+GitHub or GitHub Enterprise. The configuration for this processor lives under
+`catalog.processors.github`. Example:
+
+```yaml
+catalog:
+  processors:
+    github:
+      providers:
+        - target: https://github.com
+          token:
+            $secret:
+              env: GITHUB_PRIVATE_TOKEN
+        - target: https://ghe.example.net
+          apiBaseUrl: https://ghe.example.net/api/v3
+          rawBaseUrl: https://ghe.example.net/raw
+          token:
+            $secret:
+              env: GHE_PRIVATE_TOKEN
+```
+
+The main subkey is `providers`, where you can list the various GitHub compatible
+providers you want to be able to fetch data from. Each entry is a structure with
+up to four elements:
+
+- `target` (required): The string prefix of the location target that you want to
+  match on, with no trailing slash. For GitHub, it should be exactly
+  `https://github.com`.
+- `token` (optional): An authentication token as expected by GitHub. If
+  supplied, it will be passed along with all calls to this provider, both API
+  and raw. If it is not supplied, anonymous access will be used.
+- `apiBaseUrl` (optional): If you want to communicate using the APIv3 method
+  with this provider, specify the base URL for its endpoint here, with no
+  trailing slash. Specifically when the target is github, you can leave it out
+  to be inferred automatically. For a GitHub Enterprise installation, it is
+  commonly at `https://api.<host>` or `https://<host>/api/v3`.
+- `rawBaseUrl` (optional): If you want to communicate using the raw HTTP method
+  with this provider, specify the base URL for its endpoint here, with no
+  trailing slash. Specifically when the target is public GitHub, you can leave
+  it out to be inferred automatically. For a GitHub Enterprise installation, it
+  is commonly at `https://api.<host>` or `https://<host>/api/v3`.
+
+You need to supply either `apiBaseUrl` or `rawBaseUrl` or both (except for
+public GitHub, for which we can infer them). The `apiBaseUrl` will always be
+preferred over the other if a `token` is given, otherwise `rawBaseUrl` will be
+preferred.
+
+If you do not supply a public GitHub provider, one will be added automatically,
+silently at startup for convenience. So you only have to list it if you want to
+supply a token for it - and if you do, you can also leave out the `apiBaseUrl`
+and `rawBaseUrl` fields.
+
 ## Static Location Configuration
 
 To enable declarative catalog setups, it is possible to add locations to the

docs/features/software-catalog/descriptor-format.md

@@ -2,6 +2,8 @@
 id: descriptor-format
 title: Descriptor Format of Catalog Entities
 sidebar_label: YAML File Format
+description: Documentation on Descriptor Format of Catalog Entities which
+describes the default data shape and semantics of catalog entities
 ---
 
 This section describes the default data shape and semantics of catalog entities.
@@ -471,6 +473,7 @@ Describes the following entity kind:
 An API describes an interface that can be exposed by a component. The API can be
 defined in different formats, like [OpenAPI](https://swagger.io/specification/),
 [AsyncAPI](https://www.asyncapi.com/docs/specifications/latest/),
+[GraphQL](https://graphql.org/learn/schema/),
 [gRPC](https://developers.google.com/protocol-buffers), or other formats.
 
 Descriptor files for this kind may look as follows.
@@ -483,6 +486,8 @@ metadata:
   description: Retrieve artist details
 spec:
   type: openapi
+  lifecycle: production
+  owner: artist-relations@example.com
   definition: |
     openapi: "3.0.0"
     info:
@@ -527,6 +532,41 @@ The current set of well-known and common values for this field is:
   [Protocol Buffers](https://developers.google.com/protocol-buffers) to use with
   [gRPC](https://grpc.io/).
 
+### `spec.lifecycle` [required]
+
+The lifecycle state of the API, e.g. `production`. This field is required.
+
+The software catalog accepts any lifecycle value, but an organization should
+take great care to establish a proper taxonomy for these.
+
+The current set of well-known and common values for this field is:
+
+- `experimental` - an experiment or early, non-production API, signaling that
+  users may not prefer to consume it over other more established APIs, or that
+  there are low or no reliability guarantees
+- `production` - an established, owned, maintained API
+- `deprecated` - an API that is at the end of its lifecycle, and may disappear
+  at a later point in time
+
+### `spec.owner` [required]
+
+The owner of the API, e.g. `artist-relations@example.com`. This field is
+required.
+
+In Backstage, the owner of an API is the singular entity (commonly a team) that
+bears ultimate responsibility for the API, and has the authority and capability
+to develop and maintain it. They will be the point of contact if something goes
+wrong, or if features are to be requested. The main purpose of this field is for
+display purposes in Backstage, so that people looking at catalog items can get
+an understanding of to whom this API belongs. It is not to be used by automated
+processes to for example assign authorization in runtime systems. There may be
+others that also develop or otherwise touch the API, but there will always be
+one ultimate owner.
+
+Apart from being a string, the software catalog leaves the format of this field
+open to implementers to choose. Most commonly, it is set to the ID or email of a
+group of people in an organizational structure.
+
 ### `spec.definition` [required]
 
 The definition of the API, based on the format defined by `spec.type`. This

docs/features/software-catalog/extending-the-model.md

@@ -1,6 +1,7 @@
 ---
 id: extending-the-model
 title: Extending the model
+description: Documentation on Extending the model
 ---
 
 Backstage natively supports tracking of the following component

docs/features/software-catalog/external-integrations.md

@@ -1,6 +1,8 @@
 ---
 id: external-integrations
 title: External integrations
+description: Documentation on External integrations to integrate systems
+with Backstage
 ---
 
 Backstage natively supports storing software components in

docs/features/software-catalog/index.md

@@ -2,6 +2,8 @@
 id: software-catalog-overview
 title: Backstage Service Catalog (alpha)
 sidebar_label: Overview
+description: The Backstage Service Catalog — actually, a software catalog, since
+it includes more than just services
 ---
 
 ## What is a Service Catalog?

docs/features/software-catalog/installation.md

@@ -1,6 +1,7 @@
 ---
 id: installation
 title: Installing in your Backstage App
+description: Documentation on How to install Backstage Plugin
 ---
 
 The catalog plugin comes in two packages, `@backstage/plugin-catalog` and

docs/features/software-catalog/system-model.md

@@ -1,6 +1,7 @@
 ---
 id: system-model
 title: System Model
+description: Documentation on System Model
 ---
 
 We believe that a strong shared understanding and terminology around software

docs/features/software-catalog/well-known-annotations.md

@@ -2,6 +2,9 @@
 id: well-known-annotations
 title: Well-known Annotations on Catalog Entities
 sidebar_label: Well-known Annotations
+description: Documentation on lists a number of well known Annotations, that
+have defined semantics. They can be attached to catalog entities and consumed
+by plugins as needed
 ---
 
 This section lists a number of well known
@@ -51,13 +54,13 @@ The value of this annotation is a location reference string (see above). If this
 annotation is specified, it is expected to point to a repository that the
 TechDocs system can read and generate docs from.
 
-### backstage.io/jenkins-github-folder
+### jenkins.io/github-folder
 
 ```yaml
 # Example:
 metadata:
   annotations:
-    backstage.io/jenkins-github-folder: folder-name/job-name
+    jenkins.io/github-folder: folder-name/job-name
 ```
 
 The value of this annotation is the path to a job on Jenkins, that builds this

docs/features/software-templates/adding-templates.md

@@ -1,6 +1,7 @@
 ---
 id: adding-templates
 title: Adding your own Templates
+description: Documentation on Adding your own Templates
 ---
 
 Templates are stored in the **Service Catalog** under a kind `Template`. The

docs/features/software-templates/extending/create-your-own-preparer.md

@@ -1,6 +1,7 @@
 ---
 id: extending-preparer
 title: Create your own Preparer
+description: Documentation on Creating your own Preparer
 ---
 
 Preparers are responsible for reading the location of the definition of a

docs/features/software-templates/extending/create-your-own-publisher.md

@@ -1,6 +1,7 @@
 ---
 id: extending-publisher
 title: Create your own Publisher
+description: Documentation on Creating your own Publisher
 ---
 
 Publishers are responsible for pushing and storing the templated skeleton after

docs/features/software-templates/extending/create-your-own-templater.md

@@ -1,6 +1,7 @@
 ---
 id: extending-templater
 title: Creating your own Templater
+description: Documentation on Creating your own Templater
 ---
 
 Templaters are responsible for taking the directory path for the skeleton

docs/features/software-templates/index.md

@@ -2,12 +2,14 @@
 id: software-templates-index
 title: Backstage Software Templates
 sidebar_label: Overview
+description: The Software Templates part of Backstage is a tool that can help
+you create Components inside Backstage
 ---
 
 The Software Templates part of Backstage is a tool that can help you create
 Components inside Backstage. By default, it has the ability to load skeletons of
-code, template in some variables, and then publish the template to some location
-like GitHub.
+code, template in some variables, and then publish the template to some
+locations like GitHub or GitLab.
 
 <video width="100%" height="100%" controls>
   <source src="https://backstage.io/blog/assets/2020-08-05/feature.mp4" type="video/mp4">
@@ -38,8 +40,10 @@ internally.
 
 After filling in these variables, you'll get some more fields to fill out which
 are required for backstage usage: the owner, (which is a `user` in the backstage
-system), the `storePath` (which right now must be a GitHub Organisation), and a
-non-existing github repository name in the format `organisation/reponame`.
+system), the `storePath` (which right now must be a GitHub Organisation or
+GitHub user), a non-existing github repository name in the format
+`organisation/reponame`, and a GitHub team or user account which should be
+granted admin access to the repository.
 
 ![Enter backstage vars](../../assets/software-templates/template-picked-2.png)
 

docs/features/software-templates/installation.md

@@ -1,6 +1,7 @@
 ---
 id: installation
 title: Installing in your Backstage App
+description: Documentation on How to install Backstage App
 ---
 
 The scaffolder plugin comes in two packages, `@backstage/plugin-scaffolder` and
@@ -86,41 +87,74 @@ import {
   createRouter,
   FilePreparer,
   GithubPreparer,
+  GitlabPreparer,
   Preparers,
+  Publishers,
   GithubPublisher,
+  GitlabPublisher,
   CreateReactAppTemplater,
   Templaters,
+  RepoVisilityOptions,
 } from '@backstage/plugin-scaffolder-backend';
 import { Octokit } from '@octokit/rest';
+import { Gitlab } from '@gitbeaker/node';
 import type { PluginEnvironment } from '../types';
 import Docker from 'dockerode';
 
-export default async function createPlugin({ logger }: PluginEnvironment) {
+export default async function createPlugin({
+  logger,
+  config,
+}: PluginEnvironment) {
   const cookiecutterTemplater = new CookieCutter();
   const craTemplater = new CreateReactAppTemplater();
   const templaters = new Templaters();
-
-  // Register default templaters
   templaters.register('cookiecutter', cookiecutterTemplater);
   templaters.register('cra', craTemplater);
 
   const filePreparer = new FilePreparer();
   const githubPreparer = new GithubPreparer();
+  const gitlabPreparer = new GitlabPreparer(config);
   const preparers = new Preparers();
 
-  // Register default preparers
   preparers.register('file', filePreparer);
   preparers.register('github', githubPreparer);
+  preparers.register('gitlab', gitlabPreparer);
+  preparers.register('gitlab/api', gitlabPreparer);
 
-  // Create GitHub client with your access token from environment variables
-  const githubClient = new Octokit({ auth: process.env.GITHUB_ACCESS_TOKEN });
-  const publisher = new GithubPublisher({ client: githubClient });
+  const publishers = new Publishers();
+
+  const githubToken = config.getString('scaffolder.github.token');
+  const repoVisibility = config.getString(
+    'scaffolder.github.visibility',
+  ) as RepoVisilityOptions;
+
+  const githubClient = new Octokit({ auth: githubToken });
+  const githubPublisher = new GithubPublisher({
+    client: githubClient,
+    token: githubToken,
+    repoVisibility,
+  });
+  publishers.register('file', githubPublisher);
+  publishers.register('github', githubPublisher);
+
+  const gitLabConfig = config.getOptionalConfig('scaffolder.gitlab.api');
+
+  if (gitLabConfig) {
+    const gitLabToken = gitLabConfig.getString('token');
+    const gitLabClient = new Gitlab({
+      host: gitLabConfig.getOptionalString('baseUrl'),
+      token: gitLabToken,
+    });
+    const gitLabPublisher = new GitlabPublisher(gitLabClient, gitLabToken);
+    publishers.register('gitlab', gitLabPublisher);
+    publishers.register('gitlab/api', gitLabPublisher);
+  }
 
   const dockerClient = new Docker();
   return await createRouter({
     preparers,
     templaters,
-    publisher,
+    publishers,
     logger,
     dockerClient,
   });
@@ -167,7 +201,7 @@ catalog:
       target: https://github.com/spotify/cookiecutter-golang/blob/master/template.yaml
 ```
 
-### Runtime Dependencies
+### Runtime Dependencies / Configuration
 
 For the scaffolder backend plugin to function, it needs a GitHub access token,
 and access to a running Docker daemon. You can create a GitHub access token
@@ -177,8 +211,37 @@ docs on creating private GitHub access tokens is available
 Note that the need for private GitHub access tokens will be replaced with GitHub
 Apps integration further down the line.
 
-The GitHub access token is passed along using the `GITHUB_ACCESS_TOKEN`
-environment variable.
+#### Github
+
+The Github access token is retrieved from environment variables via the config.
+The config file needs to specify what environment variable the token is
+retrieved from. Your config should have the following objects.
+
+#### Gitlab
+
+For Gitlab, we currently support the configuration of the GitLab publisher and
+allows to configure the private access token and the base URL of a GitLab
+instance:
+
+```yaml
+scaffolder:
+  github:
+    token:
+      $secret:
+        env: GITHUB_ACCESS_TOKEN
+    visibility: public # or 'internal' or 'private'
+  gitlab:
+    api:
+      baseUrl: https://gitlab.com
+      token:
+        $secret:
+          env: SCAFFOLDER_GITLAB_PRIVATE_TOKEN
+```
+
+You can configure who can see the new repositories that the scaffolder creates
+by specifying `visibility` option. Valid options are `public`, `private` and
+`internal`. `internal` options is for GitHub Enterprise clients, which means
+public within the organization.
 
 ### Running the Backend
 

docs/features/techdocs/FAQ.md

@@ -2,6 +2,7 @@
 id: faqs
 title: TechDocs FAQ
 sidebar_label: FAQ
+description: This page answers frequently asked questions about TechDocs
 ---
 
 This page answers frequently asked questions about [TechDocs](README.md).

docs/features/techdocs/README.md

@@ -2,6 +2,8 @@
 id: techdocs-overview
 title: TechDocs Documentation
 sidebar_label: Overview
+description: TechDocs is Spotify’s homegrown docs-like-code solution built
+directly into Backstage
 ---
 
 ## What is it?

docs/features/techdocs/architecture.md

@@ -1,6 +1,7 @@
 ---
 id: architecture
 title: Architecture
+description: Documentation on Architecture
 ---
 
 ![TechDocs Big Picture](../../assets/techdocs/techdocs_big_picture.png)

docs/features/techdocs/concepts.md

@@ -1,6 +1,8 @@
 ---
 id: concepts
 title: Concepts
+description: Documentation on concepts that are introduced with
+Spotify's docs-like-code solution in Backstage
 ---
 
 This page describes concepts that are introduced with Spotify's docs-like-code

docs/features/techdocs/creating-and-publishing.md

@@ -2,6 +2,7 @@
 id: creating-and-publishing
 title: Creating and publishing your docs
 sidebar_label: Creating and Publishing Documentation
+description: Guidance on how to create and publish documentation
 ---
 
 This section will guide you through:

docs/features/techdocs/getting-started.md

@@ -1,6 +1,7 @@
 ---
 id: getting-started
 title: Getting Started
+description: Getting Started Guidelines
 ---
 
 TechDocs functions as a plugin to Backstage, so you will need to use Backstage
@@ -70,6 +71,30 @@ building and publishing of your documentation, you want to change the
 `requestUrl` to point to your storage. In this case `storageUrl` is not
 required.
 
+### Disable Docker in Docker situation (Optional)
+
+The TechDocs backend plugin runs a docker container with mkdocs to generate the
+frontend of the docs from source files (Markdown). If you are deploying
+Backstage using Docker, this will mean that your Backstage Docker container will
+try to run another Docker container for TechDocs backend.
+
+To avoid this problem, we have a configuration available. You can set a value in
+your `app-config.yaml` that tells the techdocs generator if it should run the
+`local` mkdocs or run it from `docker`. This defaults to running as `docker` if
+no config is provided.
+
+```yaml
+techdocs:
+  generators:
+    techdocs: local
+```
+
+Setting `generators.techdocs` to `local` means you will have to make sure your
+environment is compatible with techdocs. You will have to install the
+`mkdocs-techdocs-container` and 'mkdocs' package from pip, as well as graphviz
+and plantuml from your package manager. This has only been tested with python
+3.7 and python 3.8.
+
 ## Run Backstage locally
 
 Change folder to `<backstage-project-root>/packages/backend` and run the

docs/getting-started/app-custom-theme.md

@@ -1,6 +1,7 @@
 ---
 id: app-custom-theme
 title: Customize the look-and-feel of your App
+description: Documentation on Customizing look and feel of the App
 ---
 
 Backstage ships with a default theme with a light and dark mode variant. The

docs/getting-started/configure-app-with-plugins.md

@@ -1,6 +1,7 @@
 ---
 id: configure-app-with-plugins
 title: Configuring App with plugins
+description: Documentation on How Configuring App with plugins
 ---
 
 ## Adding existing plugins to your app

docs/getting-started/create-an-app.md

@@ -1,6 +1,7 @@
 ---
 id: create-an-app
 title: Create an App
+description: Documentation on Creating an App
 ---
 
 To get set up quickly with your own Backstage project you can create a Backstage

docs/getting-started/deployment-k8s.md

@@ -1,6 +1,7 @@
 ---
 id: deployment-k8s
 title: Kubernetes
+description: Documentation on Kubernetes and K8s Deployment
 ---
 
 Coming soon!

docs/getting-started/deployment-other.md

@@ -1,6 +1,7 @@
 ---
 id: deployment-other
 title: Other
+description: Documentation on different ways of Deployment
 ---
 
 ## Deploying Locally

docs/getting-started/development-environment.md

@@ -1,6 +1,8 @@
 ---
 id: development-environment
 title: Development Environment
+description: Documentation on how to get set up for doing development on
+the Backstage repository
 ---
 
 This section describes how to get set up for doing development on the Backstage

docs/getting-started/index.md

@@ -1,6 +1,7 @@
 ---
 id: index
 title: Getting Started
+description: Documentation on How to get started with Backstage
 ---
 
 There are two different ways to get started with Backstage, either by creating a

docs/getting-started/installation.md

@@ -1,6 +1,7 @@
 ---
 id: installation
 title: Installation
+description: Documentation on Installation
 ---
 
 Coming soon!

docs/getting-started/running-backstage-locally.md

@@ -1,23 +1,42 @@
 ---
 id: running-backstage-locally
 title: Running Backstage Locally
+description: Documentation on How to run Backstage Locally
 ---
 
+## Prerequisites
+
+- Node.js
+
 First make sure you are using NodeJS with an Active LTS Release, currently v12.
 This is made easy with a version manager such as
 [nvm](https://github.com/nvm-sh/nvm) which allows for version switching.
 
 ```bash
-# Checking your version
-node --version
-> v14.7.0
-
-# Adding a second node version
+# Installing a new version
 nvm install 12
 > Downloading and installing node v12.18.3...
 > Now using node v12.18.3 (npm v6.14.6)
+
+# Checking your version
+node --version
+> v12.18.3
 ```
 
+- yarn
+
+Please refer to the
+[installation instructions for yarn](https://classic.yarnpkg.com/en/docs/install/).
+
+- Docker
+
+We use Docker for few of our core features. So, you will need Docker installed
+locally to use features like Software Templates and TechDocs. Please refer to
+the
+[installation instructions for Docker](https://docs.docker.com/engine/install/).
+
+## Clone and Build
+
 To get up and running with a local Backstage to evaluate it, let's clone it off
 of GitHub and run an initial build.
 

docs/overview/adopting.md

@@ -1,6 +1,8 @@
 ---
 id: adopting
 title: Strategies for adopting
+description: Documentation on some general best practices that have been key
+to Backstage's success inside Spotify
 ---
 
 This document outlines some general best practices that have been key to

docs/overview/architecture-overview.md

@@ -1,6 +1,7 @@
 ---
 id: architecture-overview
 title: Architecture overview
+description: Documentation on Architecture overview
 ---
 
 ## Overview

docs/overview/architecture-terminology.md

@@ -1,6 +1,7 @@
 ---
 id: architecture-terminology
 title: Architecture terminology
+description: Documentation on Architecture terminology
 ---
 
 Backstage is constructed out of three parts. We separate Backstage in this way

docs/overview/background.md

@@ -1,6 +1,7 @@
 ---
 id: background
 title: The Spotify Story
+description: Documentation on Background and Story behind making of Backstage
 ---
 
 Backstage was born out of necessity at Spotify. We found that as we grew, our

docs/overview/logos.md

@@ -2,6 +2,7 @@
 id: logos
 title: Logos
 sidebar_label: Logo assets
+description: Guidelines for how to use the Backstage logos and icons
 ---
 
 Guidelines for how to use the Backstage logo and icon can be found

docs/overview/roadmap.md

@@ -1,6 +1,7 @@
 ---
 id: roadmap
 title: Project roadmap
+description: Roadmap of Backstage Project
 ---
 
 ## Current status

docs/overview/support.md

@@ -1,6 +1,7 @@
 ---
 id: support
 title: Support and community
+description: Support and Community Details and Links
 ---
 
 - [Discord chatroom](https://discord.gg/MUpMjP2) - Get support or discuss the

docs/overview/vision.md

@@ -1,6 +1,8 @@
 ---
 id: vision
 title: Vision
+description: Goal is to provide engineers with the best developer experience in
+the world
 ---
 
 Our goal is to provide engineers with the best developer experience in the

docs/overview/what-is-backstage.md

@@ -1,6 +1,8 @@
 ---
 id: what-is-backstage
 title: What is Backstage?
+description: Backsatge is an open platform for building developer portals.
+Powered by a centralized service catalog, Backstage restores order to your microservices and infrastructure
 ---
 
 ![service-catalog](https://backstage.io/blog/assets/6/header.png)

docs/plugins/add-to-marketplace.md

@@ -1,6 +1,7 @@
 ---
 id: add-to-marketplace
 title: Add to Marketplace
+description: Documentation on Adding Plugin to Marketplace
 ---
 
 ## Adding a Plugin to the Marketplace

docs/plugins/backend-plugin.md

@@ -1,6 +1,7 @@
 ---
 id: backend-plugin
 title: Backend plugin
+description: Documentation on Backend plugin
 ---
 
 ## TODO

docs/plugins/call-existing-api.md

@@ -1,6 +1,8 @@
 ---
 id: call-existing-api
 title: Call Existing API
+description: Describes the various options that Backstage frontend plugins have,
+in communicating with service APIs that already exist
 ---
 
 This article describes the various options that Backstage frontend plugins have,

docs/plugins/create-a-plugin.md

@@ -1,6 +1,7 @@
 ---
 id: create-a-plugin
 title: Create a Backstage Plugin
+description: Documentation on How to Create a Backstage Plugin
 ---
 
 A Backstage Plugin adds functionality to Backstage.

docs/plugins/existing-plugins.md

@@ -1,6 +1,7 @@
 ---
 id: existing-plugins
 title: Existing plugins
+description: Lists of existing open source plugins
 ---
 
 ## Open source plugins

docs/plugins/index.md

@@ -1,6 +1,7 @@
 ---
 id: index
 title: Intro to plugins
+description: Documentation on Introduction to Plugins
 ---
 
 Backstage is a single-page application composed of a set of plugins.

docs/plugins/integrating-plugin-into-service-catalog.md

@@ -1,6 +1,7 @@
 ---
 id: integrating-plugin-into-service-catalog
 title: Integrate into the Service Catalog
+description: Documentation on How to integrate plugin into service catalog
 ---
 
 > This is an advanced use case and currently is an experimental feature. Expect

docs/plugins/plugin-development.md

@@ -1,6 +1,7 @@
 ---
 id: plugin-development
 title: Plugin Development
+description: Documentation on Plugin Development
 ---
 
 Backstage plugins provide features to a Backstage App.

docs/plugins/proxying.md

@@ -1,6 +1,7 @@
 ---
 id: proxying
 title: Proxying
+description: Documentation on Proxying
 ---
 
 ## Overview

docs/plugins/publish-private.md

@@ -1,6 +1,7 @@
 ---
 id: publish-private
 title: Publish private
+description: Documentation on How to Publish private
 ---
 
 ## TODO

docs/plugins/publishing.md

@@ -1,6 +1,7 @@
 ---
 id: publishing
 title: Publishing
+description: Documentation on Publishing NPM packages
 ---
 
 ## NPM

docs/plugins/structure-of-a-plugin.md

@@ -1,6 +1,7 @@
 ---
 id: structure-of-a-plugin
 title: Structure of a Plugin
+description: Details about structure of a plugin
 ---
 
 Nice, you have a new plugin! We'll soon see how we can develop it into doing

docs/plugins/testing.md

@@ -1,6 +1,7 @@
 ---
 id: testing
 title: Testing with Jest
+description: Documentation on How to do unit testing with Jest
 ---
 
 Backstage uses [Jest](https://facebook.github.io/jest/) for all our unit testing

docs/reference/createPlugin-feature-flags.md

@@ -1,6 +1,7 @@
 ---
 id: createPlugin-feature-flags
 title: createPlugin - feature flags
+description: Documentation on createPlugin - feature flags
 ---
 
 The `featureFlags` object passed to the `register` function makes it possible

docs/reference/createPlugin-router.md

@@ -1,6 +1,7 @@
 ---
 id: createPlugin-router
 title: createPlugin - router
+description: Documentation on createPlugin - router
 ---
 
 The router that is passed to the `register` function makes it possible for