Merge branch 'master' into identity-api-client-interface

docs/auth/identity-resolver.md

@@ -207,7 +207,7 @@ of lower-level calls:
 
 ```ts
 // File: packages/backend/src/plugins/auth.ts
-import { getDefaultOwnershipRefs } from '@backstage/plugin-auth-backend';
+import { getDefaultOwnershipEntityRefs } from '@backstage/plugin-auth-backend';
 
 export default async function createPlugin(
   // ...
@@ -236,7 +236,7 @@ export default async function createPlugin(
         // an entity you will need to replace this step as well.
         //
         // You might also replace it if you for example want to filter out certain groups.
-        const ownershipRefs = getDefaultOwnershipRefs(entity);
+        const ownershipRefs = getDefaultOwnershipEntityRefs(entity);
 
         // The last step is to issue the token, where we might provide more options in the future.
         return ctx.issueToken({

docs/features/kubernetes/configuration.md

@@ -373,23 +373,43 @@ view the Kubernetes API docs for your Kubernetes version (e.g.
 
 ### Role Based Access Control
 
-The current RBAC permissions required are read-only cluster wide, for the
-following objects:
+The current RBAC permissions required are read-only cluster wide, the below
+Kubernetes manifest describes which objects are required and will ensure
+the plugin functions correctly:
 
-- pods
-- services
-- configmaps
-- deployments
-- replicasets
-- horizontalpodautoscalers
-- ingresses
-- statefulsets
-
-The following RBAC permissions are required on the batch API group for the
-following objects:
-
-- jobs
-- cronjobs
+```yaml
+---
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRole
+metadata:
+  name: backstage-read-only
+rules:
+  - apiGroups:
+      - '*'
+    resources:
+      - pods
+      - configmaps
+      - services
+      - deployments
+      - replicasets
+      - horizontalpodautoscalers
+      - ingresses
+      - statefulsets
+      - limitranges
+    verbs:
+      - get
+      - list
+      - watch
+  - apiGroups:
+      - batch
+    resources:
+      - jobs
+      - cronjobs
+    verbs:
+      - get
+      - list
+      - watch
+```
 
 ## Surfacing your Kubernetes components as part of an entity
 

docs/features/kubernetes/installation.md

@@ -62,13 +62,16 @@ add the following:
 import { KubernetesBuilder } from '@backstage/plugin-kubernetes-backend';
 import { Router } from 'express';
 import { PluginEnvironment } from '../types';
+import { CatalogClient } from '@backstage/catalog-client';
 
 export default async function createPlugin(
   env: PluginEnvironment,
 ): Promise<Router> {
+  const catalogApi = new CatalogClient({ discoveryApi: env.discovery });
   const { router } = await KubernetesBuilder.createBuilder({
     logger: env.logger,
     config: env.config,
+    catalogApi,
   }).build();
   return router;
 }

docs/integrations/bitbucket/locations.md

@@ -26,6 +26,16 @@ integrations:
       token: ${BITBUCKET_SERVER_TOKEN}
 ```
 
+or with Basic Auth
+
+```yaml
+integrations:
+  bitbucketServer:
+    - host: bitbucket.company.com
+      username: ${BITBUCKET_SERVER_USERNAME}
+      password: ${BITBUCKET_SERVER_PASSWORD}
+```
+
 Directly under the `bitbucketServer` key is a list of provider configurations, where
 you can list the Bitbucket Server providers you want to fetch data from. Each entry is
 a structure with the following elements:
@@ -34,5 +44,9 @@ a structure with the following elements:
 - `token` (optional):
   An [personal access token](https://confluence.atlassian.com/bitbucketserver/personal-access-tokens-939515499.html)
   as expected by Bitbucket Server.
+- `username` (optional):
+  use for [Basic Auth](https://developer.atlassian.com/server/bitbucket/how-tos/command-line-rest/#authentication) for Bitbucket Server.
+- `password` (optional):
+  use for [Basic Auth](https://developer.atlassian.com/server/bitbucket/how-tos/command-line-rest/#authentication) for Bitbucket Server.
 - `apiBaseUrl` (optional): The URL of the Bitbucket Server API. For self-hosted
   installations, it is commonly at `https://<host>/rest/api/1.0`.

docs/plugins/customization.md

@@ -0,0 +1,68 @@
+---
+id: customization
+title: Customization
+description: Documentation on adding a customization logic to the plugin
+---
+
+## Overview
+
+The Backstage core logic provides a possibility to make the component customizable in such a way that the application
+developer can redefine the labels, icons, elements or even completely replace the component. It's up to each plugin
+to decide what can be customized.
+
+## For a plugin developer
+
+When you are creating your plugin, you have a possibility to use a metadata field and define there all
+customizable elements. For example
+
+```typescript jsx
+const plugin = createPlugin({
+  id: 'my-plugin',
+  __experimentalConfigure(
+    options?: CatalogInputPluginOptions,
+  ): CatalogPluginOptions {
+    const defaultOptions = {
+      createButtonTitle: 'Create',
+    };
+    return { ...defaultOptions, ...options };
+  },
+});
+```
+
+And the rendering part of the exposed component can retrieve that metadata as:
+
+```typescript jsx
+export type CatalogPluginOptions = {
+  createButtonTitle: string;
+};
+
+export type CatalogInputPluginOptions = {
+  createButtonTitle: string;
+};
+
+export const useCatalogPluginOptions = () =>
+  usePluginOptions<CatalogPluginOptions>();
+
+export function DefaultMyPluginWelcomePage() {
+  const { createButtonTitle } = useCatalogPluginOptions();
+
+  return (
+    <div>
+      <button>{createButtonTitle}</button>
+    </div>
+  );
+}
+```
+
+## For an application developer using the plugin
+
+The way to reconfigure the default values provided by the plugin you can do it via reconfigure method, defined on the
+plugin. Example:
+
+```typescript jsx
+import { myPlugin } from '@backstage/my-plugin';
+
+myPlugin.__experimentalReconfigure({
+  createButtonTitle: 'New',
+});
+```