fix multi-line links

Signed-off-by: Patrik Oldsberg <poldsberg@gmail.com>

docs/features/kubernetes/configuration.md

@@ -198,8 +198,7 @@ in namespace `NAMESPACE` and it has adequate
 [permissions](#role-based-access-control), here are some sample procedures to
 procure a long-lived service account token for use with this provider:
 
-- On versions of Kubernetes [prior to
-  1.24](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.24.md#no-really-you-must-read-this-before-you-upgrade-1),
+- On versions of Kubernetes [prior to 1.24](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.24.md#no-really-you-must-read-this-before-you-upgrade-1),
   you could get an (automatically-generated) token for a service account with:
 
   ```sh
@@ -209,8 +208,7 @@ procure a long-lived service account token for use with this provider:
   | base64 --decode
   ```
 
-- For Kubernetes 1.24+, as described in [this
-  guide](https://kubernetes.io/docs/concepts/configuration/secret/#service-account-token-secrets),
+- For Kubernetes 1.24+, as described in [this guide](https://kubernetes.io/docs/concepts/configuration/secret/#service-account-token-secrets),
   you can obtain a long-lived token by creating a secret:
 
   ```sh
@@ -235,8 +233,7 @@ procure a long-lived service account token for use with this provider:
 If a cluster has `authProvider: serviceAccount` and the `serviceAccountToken`
 field is omitted, Backstage will ignore the configured URL and certificate data,
 instead attempting to access the Kubernetes API via an in-cluster client as in
-[this
-example](https://github.com/kubernetes-client/javascript/blob/master/examples/in-cluster.js).
+[this example](https://github.com/kubernetes-client/javascript/blob/master/examples/in-cluster.js).
 
 ##### `clusters.\*.oidcTokenProvider` (optional)
 

docs/features/kubernetes/proxy.md

@@ -7,12 +7,10 @@ description: Interacting with the Kubernetes API in Backstage plugins
 
 [Contributors](https://backstage.io/docs/overview/glossary#backstage-user-profiles) wanting to
 create developer portal experiences based on data from Kubernetes (e.g. for
-interacting with [Custom
-Resources](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
+interacting with [Custom Resources](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
 beyond the default behaviors of the existing Kubernetes plugin) can leverage the
 Kubernetes backend plugin's proxy endpoint to allow them to make arbitrary
-requests to the [REST
-API](https://kubernetes.io/docs/reference/using-api/api-concepts/).
+requests to the [REST API](https://kubernetes.io/docs/reference/using-api/api-concepts/).
 
 Here is a snippet fetching namespaces using the `KubernetesBackendClient` library
 
@@ -31,8 +29,7 @@ await kubernetesApi.proxy(CLUSTER_NAME, '/api/v1/namespaces');
 The proxy will interpret the
 [`Backstage-Kubernetes-Cluster`](https://backstage.io/docs/reference/plugin-kubernetes-backend.header_kubernetes_cluster)
 header as the name of the cluster to target. This name will be compared to each cluster
-returned by all the configured [cluster
-locators](https://backstage.io/docs/features/kubernetes/configuration#clusterlocatormethods)
+returned by all the configured [cluster locators](https://backstage.io/docs/features/kubernetes/configuration#clusterlocatormethods)
 -- the first cluster whose [`name` field](https://backstage.io/docs/features/kubernetes/configuration#clustersname) matches
 the value in the header will be targeted.
 
@@ -48,12 +45,10 @@ The proxy expects a `KubernetesAuthTranslator` to be provided that is used to de
 ## Authentication
 
 The proxy has no provisions for mTLS, so it cannot be used to connect to
-clusters using the [x509 Client
-Certs](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#x509-client-certs)
+clusters using the [x509 Client Certs](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#x509-client-certs)
 authentication strategy.\
 The current `/proxy` Implementation expects a
-[Bearer
-token](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#putting-a-bearer-token-in-a-request)
+[Bearer token](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#putting-a-bearer-token-in-a-request)
 to be provided as a `Backstage-Kubernetes-Authorization` header for a target cluster. This token will be used as the `Authorization` header when forwarding a request to a target cluster.
 
 ## How to disable the proxy endpoint via PermissionPolicy
@@ -104,8 +99,7 @@ even if a valid ID token was attached that a cluster would authorize.
 
 ## Other known limitations
 
-The proxy as it was released in [Backstage
-1.9](https://github.com/backstage/backstage/blob/master/docs/releases/v1.9.0-changelog.md#patch-changes-15)
+The proxy as it was released in [Backstage 1.9](../../releases/v1.9.0-changelog.md#patch-changes-15)
 has a known bug:
 
 - [#15901](https://github.com/backstage/backstage/issues/15901) - it cannot

docs/features/software-catalog/index.md

@@ -40,8 +40,7 @@ browse the catalog at `http://localhost:3000`.
 
 ## Adding components to the catalog
 
-The source of truth for the components in your software catalog are [metadata
-YAML files](descriptor-format.md) stored in source control (GitHub, GitHub
+The source of truth for the components in your software catalog are [metadata YAML files](descriptor-format.md) stored in source control (GitHub, GitHub
 Enterprise, GitLab, ...). Repositories can include one or multiple metadata
 files. Usually the metadata file is located in the repository root. This is not
 a formal requirement & metadata files can be placed anywhere in the repository.