Merge branch 'master' into add-default-enviroment

docs/features/kubernetes/configuration.md

@@ -441,7 +441,7 @@ Base64-encoded certificate authority bundle in PEM format. The Kubernetes client
 will verify that the TLS certificate presented by the API server is signed by
 this CA.
 
-This value could be obtained via inspecting the kubeconfig file (usually
+This value could be obtained via inspecting the `kubeconfig` file (usually
 at `~/.kube/config`) under `clusters[*].cluster.certificate-authority-data`. For
 GKE, execute the following command to obtain the value
 
@@ -619,7 +619,7 @@ The custom resource's group.
 
 #### `customResources.\*.apiVersion`
 
-The custom resource's apiVersion.
+The custom resource's `apiVersion`.
 
 #### `customResources.\*.plural`
 

docs/features/search/declarative-integration.md

@@ -161,13 +161,13 @@ The `createSearchResultItemExtension` function returns a Backstage's extension r
 
 In this object, you can see exactly what will happen once the custom extension is installed:
 
-- **[1] $$type**: declares that the object represents an extension;
-- **[2] id**: Is a unique identification for the extension, the `plugin.search.result.item.techdocs` is the key used to configure the extension in the `app-config.yaml` file;
-- **[3] at**: It represents the extension attachment point, so the value `plugin.search.page/items` says that the `TechDocs`'s search result item output will be injected as input on the "items" attachment expected by the search page extension;
-- **[4] inputs**: in this case is an empty object because this extension doesn't expect inputs;
-- **[5] output**: Object representing the artifact produced by the `TechDocs` result item extension, on the example, it is a react component reference;
-- **[6] configSchema**: represents the `TechDocs` search result item configuration definition, this is the same schema that adopters will use for customizing the extension via `app-config.yaml` file;
-- **[7] disable**: Says that the result item extension will be enable by default when the `TechDocs` plugin is installed in the app.
+- **[1] `$$type`**: declares that the object represents an extension;
+- **[2] `id`**: Is a unique identification for the extension, the `plugin.search.result.item.techdocs` is the key used to configure the extension in the `app-config.yaml` file;
+- **[3] `at`**: It represents the extension attachment point, so the value `plugin.search.page/items` says that the `TechDocs`'s search result item output will be injected as input on the "items" attachment expected by the search page extension;
+- **[4] `inputs`**: in this case is an empty object because this extension doesn't expect inputs;
+- **[5] `output`**: Object representing the artifact produced by the `TechDocs` result item extension, on the example, it is a react component reference;
+- **[6] `configSchema`**: represents the `TechDocs` search result item configuration definition, this is the same schema that adopters will use for customizing the extension via `app-config.yaml` file;
+- **[7] `disable`**: Says that the result item extension will be enable by default when the `TechDocs` plugin is installed in the app.
 
 To complete the development cycle for creating a custom search result item extension, we should provide the extension via `TechDocs` plugin:
 

docs/features/search/how-to-guides.md

@@ -116,7 +116,7 @@ indexBuilder.addCollator({
 The default highlighting styling for matched terms in search results is your
 browsers default styles for the `<mark>` HTML tag. If you want to customize
 how highlighted terms look you can follow Backstage's guide on how to
-[Customize the look-and-feel of your App](https://backstage.io/docs/getting-started/app-custom-theme)
+[Customizing Your App's UI](https://backstage.io/docs/conf/user-interface)
 to create an override with your preferred styling.
 
 For example, using the new MUI V4+V5 unified theming method, the following will result

docs/features/software-catalog/api.md

@@ -175,7 +175,7 @@ Some more real world usable examples:
 
 #### Ordering
 
-By default the entities are returned ordered by their internal uid. You can
+By default the entities are returned ordered by their internal `uid`. You can
 customize the `orderField` query parameters to affect that ordering.
 
 For example, to return entities by their name:

docs/features/software-catalog/catalog-customization.md

@@ -571,10 +571,8 @@ Finally, entity predicates also support value operators that can be used in plac
 ```json
 {
   "filter": {
-    {
-      "kind": "component",
-      "spec.type": { "$in": ["service", "website"] }
-    },
+    "kind": "component",
+    "spec.type": { "$in": ["service", "website"] }
   }
 }
 ```
@@ -695,6 +693,6 @@ filter:
   relations:
     $contains:
       type: ownedBy
-      target:
+      targetRef:
         $in: [group:default/admins, group:default/viewers]
 ```

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

@@ -28,23 +28,23 @@ Backstage comes with a number of catalog concepts out of the box:
 
 We'll list different possibilities for extending this below.
 
-## Adding a New apiVersion of an Existing Kind
+## Adding a New `apiVersion` of an Existing Kind
 
 Example intents:
 
 > "I want to evolve this core kind, tweaking the semantics a bit so I will bump
-> the apiVersion a step"
+> the `apiVersion` a step"
 
 > "This core kind is a decent fit but we want to evolve it at will so we'll move
-> it to our own company's apiVersion space and use that instead of
+> it to our own company's `apiVersion` space and use that instead of
 > `backstage.io`."
 
-The `backstage.io` apiVersion space is reserved for use by the Backstage
+The `backstage.io` `apiVersion` space is reserved for use by the Backstage
 maintainers. Please do not change or add versions within that space.
 
-If you add an [apiVersion](descriptor-format.md#apiversion-and-kind-required)
+If you add an [`apiVersion`](descriptor-format.md#apiversion-and-kind-required)
 space of your own, you are effectively branching out from the underlying kind
-and making your own. An entity kind is identified by the apiVersion + kind pair,
+and making your own. An entity kind is identified by the `apiVersion` + `kind` pair,
 so even though the resulting entity may be similar to the core one, there will
 be no guarantees that plugins will be able to parse or understand its data. See
 below about adding a new kind.
@@ -57,7 +57,7 @@ Example intents:
 > thing that is a poor fit for either of the builtins."
 
 > "This core kind is a decent fit but we want to evolve it at will so we'll move
-> it to our own company's apiVersion space and use that instead of
+> it to our own company's `apiVersion` space and use that instead of
 > `backstage.io`."
 
 A [kind](descriptor-format.md#apiversion-and-kind-required) is an overarching
@@ -67,7 +67,7 @@ variety of needs that one may want to model in Backstage. The primary ambition
 is to map things to these kinds, but sometimes you may want or need to extend
 beyond them.
 
-Introducing a new apiVersion is basically the same as adding a new kind. Bear in
+Introducing a new `apiVersion` is basically the same as adding a new kind. Bear in
 mind that most plugins will be compiled against the builtin
 `@backstage/catalog-model` package and have expectations that kinds align with
 that.

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

@@ -28,23 +28,23 @@ Backstage comes with a number of catalog concepts out of the box:
 
 We'll list different possibilities for extending this below.
 
-## Adding a New apiVersion of an Existing Kind
+## Adding a New `apiVersion` of an Existing Kind
 
 Example intents:
 
 > "I want to evolve this core kind, tweaking the semantics a bit so I will bump
-> the apiVersion a step"
+> the `apiVersion` a step"
 
 > "This core kind is a decent fit but we want to evolve it at will so we'll move
-> it to our own company's apiVersion space and use that instead of
+> it to our own company's `apiVersion` space and use that instead of
 > `backstage.io`."
 
-The `backstage.io` apiVersion space is reserved for use by the Backstage
+The `backstage.io` `apiVersion` space is reserved for use by the Backstage
 maintainers. Please do not change or add versions within that space.
 
-If you add an [apiVersion](descriptor-format.md#apiversion-and-kind-required)
+If you add an [`apiVersion`](descriptor-format.md#apiversion-and-kind-required)
 space of your own, you are effectively branching out from the underlying kind
-and making your own. An entity kind is identified by the apiVersion + kind pair,
+and making your own. An entity kind is identified by the `apiVersion` + `kind` pair,
 so even though the resulting entity may be similar to the core one, there will
 be no guarantees that plugins will be able to parse or understand its data. See
 below about adding a new kind.
@@ -57,7 +57,7 @@ Example intents:
 > thing that is a poor fit for either of the builtins."
 
 > "This core kind is a decent fit but we want to evolve it at will so we'll move
-> it to our own company's apiVersion space and use that instead of
+> it to our own company's `apiVersion` space and use that instead of
 > `backstage.io`."
 
 A [kind](descriptor-format.md#apiversion-and-kind-required) is an overarching
@@ -67,7 +67,7 @@ variety of needs that one may want to model in Backstage. The primary ambition
 is to map things to these kinds, but sometimes you may want or need to extend
 beyond them.
 
-Introducing a new apiVersion is basically the same as adding a new kind. Bear in
+Introducing a new `apiVersion` is basically the same as adding a new kind. Bear in
 mind that most plugins will be compiled against the builtin
 `@backstage/catalog-model` package and have expectations that kinds align with
 that.

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

@@ -775,7 +775,7 @@ sent. Luckily many external systems provide ETag support to check for changes
 which usually doesn't count towards the quota and saves resources both
 internally and externally.
 
-The catalog has built in support for leveraging ETags when refreshing external
+The catalog has built in support for leveraging `ETag`s when refreshing external
 locations in GitHub. This example aims to demonstrate how to add the same
 behavior for `system-x` that we implemented earlier.
 

docs/features/software-catalog/index.md

@@ -126,7 +126,7 @@ _starring_ of components:
 The software catalog is a great way to organize the infrastructure tools you use
 to manage the software. This is how Backstage creates one developer portal for
 all your tools. Rather than asking teams to jump between different
-infrastructure UIs (and incurring additional cognitive overhead each time they
+infrastructure user interfaces (and incurring additional cognitive overhead each time they
 make a context switch), most of these tools can be organized around the entities
 in the catalog.
 

docs/features/software-catalog/life-of-an-entity.md

@@ -133,7 +133,7 @@ the order of registration depends on the order in which the modules are loaded
 by the framework.
 
 It's possible to customize the order of the processors by modifying the
-`catalog.processors.<processorName>.priority` configuration option.
+`catalog.processorOptions.<processorName>.priority` configuration option.
 The default priority is `20`, and lower value means that the processor runs earlier.
 
 :::