RHIDP-8551 fixed the Vale alert: AsciiDocDITA.AuthorLine (#1366)

themr0c · web-flow · commit c37a0fbe6828 · 2025-09-10T15:59:12.000+02:00
diff --git a/modules/conscious-language.adoc b/modules/conscious-language.adoc
@@ -6,6 +6,7 @@ Add this to the preface.
 [discrete]
 [id="making-open-source-more-inclusive"]
 = Making open source more inclusive
+
 Red Hat is committed to replacing problematic language in our code, documentation, and web properties.
 We are beginning with these four terms: master, slave, blacklist, and whitelist.
 Because of the enormity of this endeavor, these changes will be implemented gradually over several upcoming releases.
diff --git a/modules/dynamic-plugins/con-dynamic-plugins-cache.adoc b/modules/dynamic-plugins/con-dynamic-plugins-cache.adoc
@@ -1,7 +1,8 @@
 [id="con-dynamic-plugin-cache_{context}"]
-
 = Using the dynamic plugins cache
-The dynamic plugins cache in {product} ({product-very-short}) enhances the installation process and reduces platform boot time by storing previously installed plugins. If the configuration remains unchanged, this feature prevents the need to re-download plugins on subsequent boots.
+
+The dynamic plugins cache in {product} ({product-very-short}) enhances the installation process and reduces platform boot time by storing previously installed plugins.
+If the configuration remains unchanged, this feature prevents the need to re-download plugins on subsequent boots.
 
 When you enable dynamic plugins cache:
 
@@ -11,4 +12,4 @@ When you enable dynamic plugins cache:
 * Plugins that are disabled since the previous boot are automatically removed.
 
 [NOTE]
-To enable the dynamic plugins cache in {product-very-short}, the plugins directory `dynamic-plugins-root` must be a persistent volume. 
+To enable the dynamic plugins cache in {product-very-short}, the plugins directory `dynamic-plugins-root` must be a persistent volume.
diff --git a/modules/dynamic-plugins/proc-creating-a-pvc-for-the-dynamic-plugin-cache-by-using-helm.adoc b/modules/dynamic-plugins/proc-creating-a-pvc-for-the-dynamic-plugin-cache-by-using-helm.adoc
@@ -1,13 +1,15 @@
 [id="proc-creating-a-pvc-for-the-dynamic-plugin-cache-by-using-helm_{context}"]
 = Creating a PVC for the dynamic plugin cache using the Helm Chart
+
 For Helm chart installations, if you require the dynamic plugin cache to persist across pod restarts, you must create a persistent volume claim (PVC) and configure the Helm chart to use it.
 
 .Prerequisites
 * You have installed {product} using the Helm chart.
 * You have installed the {openshift-cli}.
 
-.Procedure 
-. Create the persistent volume definition. For example: 
+.Procedure
+. Create the persistent volume definition.
+For example:
 +
 [source,yaml]
 ----
@@ -25,7 +27,7 @@ spec:
 +
 [NOTE]
 ====
-This example uses `ReadWriteOnce` as the access mode which prevents multiple replicas from sharing the PVC across different nodes. 
+This example uses `ReadWriteOnce` as the access mode which prevents multiple replicas from sharing the PVC across different nodes.
 To run multiple replicas on different nodes, depending on your storage driver, you must use an access mode such as `ReadWriteMany`.
 ====
 
@@ -35,7 +37,8 @@ To run multiple replicas on different nodes, depending on your storage driver, y
 ----
 oc apply -f pvc.yaml
 ----
-. Configure the Helm chart to use the PVC. For example:
+. Configure the Helm chart to use the PVC.
+For example:
 +
 [source,yaml]
 ----
@@ -69,4 +72,4 @@ upstream:
 [NOTE]
 ====
 When you configure the Helm chart to use the PVC, you must also include the link:https://github.com/redhat-developer/rhdh-chart/blob/release-{product-version}/charts/backstage/values.yaml#L145-L181[`extraVolumes`] defined in the default Helm chart.
-====
+====
diff --git a/modules/dynamic-plugins/proc-extensions-disabling.adoc b/modules/dynamic-plugins/proc-extensions-disabling.adoc
@@ -1,6 +1,8 @@
 [id="rhdh-extensions-plugins-disabling_{context}"]
 = Removing Extensions
-The Extensions feature plugins are preinstalled in {product} ({product-very-short}) and enabled by default. If you want to remove Extensions from your {product-very-short} instance, you can disable the relevant plugins.
+
+The Extensions feature plugins are preinstalled in {product} ({product-very-short}) and enabled by default.
+If you want to remove Extensions from your {product-very-short} instance, you can disable the relevant plugins.
 
 .Procedure
 . To disable the the Extensions feature plugins, edit your `dynamic-plugins.yaml` with the following content.
@@ -18,4 +20,5 @@ plugins:
 ----
 
 [NOTE]
-If you disable the Extensions feature plugins, the *Catalog* and *Installed* tabs will also be removed. You can still view installed plugins by clicking on *Administration* > *Extensions*.
+If you disable the Extensions feature plugins, the *Catalog* and *Installed* tabs will also be removed.
+You can still view installed plugins by clicking on *Administration* > *Extensions*.
diff --git a/modules/dynamic-plugins/proc-extensions-installing-plugins.adoc b/modules/dynamic-plugins/proc-extensions-installing-plugins.adoc
@@ -1,5 +1,6 @@
 [id="proc-extensions-installing-plugins_{context}"]
 = Installing plugins by using Extensions
+
 You can install and configure plugins by using Extensions.
 
 .Prerequisites
diff --git a/modules/dynamic-plugins/proc-topology-install.adoc b/modules/dynamic-plugins/proc-topology-install.adoc
@@ -1,4 +1,5 @@
-= Installation
+= Installing the Topology plugin
+
 The Topology plugin enables you to visualize the workloads such as Deployment, Job, Daemonset, Statefulset, CronJob, Pods and Virtual Machines powering any service on your Kubernetes cluster.
 
 .Prerequisites
@@ -9,7 +10,8 @@ The Topology plugin enables you to visualize the workloads such as Deployment, J
 If you have the {product-short} Kubernetes plugin configured, then the `ClusterRole` is already granted.
 
 .Procedure
-* The Topology plugin is pre-loaded in {product-short} with basic configuration properties. To enable it, set the disabled property to false as follows:
+* The Topology plugin is pre-loaded in {product-short} with basic configuration properties.
+To enable it, set the disabled property to false as follows:
 +
 .`{my-app-config-file}` fragment
 [source,yaml]
diff --git a/modules/dynamic-plugins/ref-catalog-plugin.adoc b/modules/dynamic-plugins/ref-catalog-plugin.adoc
@@ -1,4 +1,5 @@
 = Plugin cards
+
 For each plugin card, the following details are displayed:
 
 Badge:: The following badges are defined:
@@ -12,7 +13,8 @@ No badge is displayed if a plugin does not match any of these definitions.
 Icon:: The plugin icon (base64).
 Name:: The plugin name.
 Author(s):: A single author name or multiple author names if a plugin is developed by multiple authors.
-Category:: The categories that are displayed in the filter and labels. Only one category is shown on the card but any other categories that you select will apply when you use the category filter.
+Category:: The categories that are displayed in the filter and labels.
+Only one category is shown on the card but any other categories that you select will apply when you use the category filter.
 Short description:: Short description that is shown on the cards (text).
 Read more link:: Clickable link to open the plugin details page.
 
@@ -30,4 +32,4 @@ Versions:: Displays the plugin's name, version, role, supported version, and ins
 
 For example:
 
-image::rhdh-plugins-reference/extensions-catalog-sidebar.png[Extensions Catalog sidebar]
+image::rhdh-plugins-reference/extensions-catalog-sidebar.png[Extensions Catalog sidebar]
diff --git a/modules/dynamic-plugins/ref-configuring-the-dynamic-plugins-cache.adoc b/modules/dynamic-plugins/ref-configuring-the-dynamic-plugins-cache.adoc
@@ -1,23 +1,27 @@
 [id="ref-configuring-the-dynamic-plugins-cache_{context}"]
 = Configuring the dynamic plugins cache
+
 You can set the following optional dynamic plugin cache parameters in your `dynamic-plugins.yaml` file:
 
-* `forceDownload`: Set the value to `true` to force a reinstall of the plugin, bypassing the cache. The default value is `false`. 
+* `forceDownload`: Set the value to `true` to force a reinstall of the plugin, bypassing the cache.
+The default value is `false`.
 
-* `pullPolicy`: Similar to the `forceDownload` parameter and is consistent with other image container platforms. You can use one of the following values for this key:
+* `pullPolicy`: Similar to the `forceDownload` parameter and is consistent with other image container platforms.
+You can use one of the following values for this key:
 
 ** `Always`: This value compares the image digest in the remote registry and downloads the artifact if it has changed, even if the plugin was previously downloaded.
 ** `IfNotPresent`: This value downloads the artifact if it is not already present in the dynamic-plugins-root folder, without checking image digests.
 +
-[NOTE] 
-The `pullPolicy` setting is also applied to the NPM downloading method, although `Always` will download the remote artifact without a digest check. The existing `forceDownload` option remains functional, however, the `pullPolicy` option takes precedence. The `forceDownload` option may be deprecated in a future {product-short} release.
+[NOTE]
+The `pullPolicy` setting is also applied to the NPM downloading method, although `Always` will download the remote artifact without a digest check.
+The existing `forceDownload` option remains functional, however, the `pullPolicy` option takes precedence.
+The `forceDownload` option may be deprecated in a future {product-short} release.
 
 .Example `dynamic-plugins.yaml` file configuration to download the remote artifact without a digest check:
-
 [source,yaml]
 ----
 plugins:
   - disabled: false
     pullPolicy: Always
     package: 'oci://quay.io/example-org/example-plugin:v1.0.0!internal-backstage-plugin-example'
-----
+----
diff --git a/modules/importing-repositories/procedure-enabling-the-bulk-import-from-github-feature.adoc b/modules/importing-repositories/procedure-enabling-the-bulk-import-from-github-feature.adoc
@@ -1,15 +1,14 @@
 [id="enabling-and-giving-access-to-the-bulk-import-feature"]
 = Enabling and giving access to the Bulk Import feature
+
 You can enable the Bulk Import feature for users and give them the necessary permissions to access it.
 
 .Prerequisites
 * You have xref:enabling-github-repository-discovery[enabled GitHub repository discovery].
 
 .Procedure
-
 . The Bulk Import plugins are installed but disabled by default.
-To enable the `./dynamic-plugins/dist/red-hat-developer-hub-backstage-plugin-bulk-import-backend-dynamic` and `./dynamic-plugins/dist/red-hat-developer-hub-backstage-plugin-bulk-import` plugins,
-edit your `dynamic-plugins.yaml` with the following content:
+To enable the `./dynamic-plugins/dist/red-hat-developer-hub-backstage-plugin-bulk-import-backend-dynamic` and `./dynamic-plugins/dist/red-hat-developer-hub-backstage-plugin-bulk-import` plugins, edit your `dynamic-plugins.yaml` with the following content:
 +
 .`dynamic-plugins.yaml` fragment
 [source,yaml]
@@ -32,7 +31,8 @@ p, role:default/bulk-import, bulk.import, use, allow
 g, user:default/__<your_user>__, role:default/bulk-import
 ----
 +
-Note that only {product-short} administrators or users with the `bulk.import` permission can use the Bulk Import feature. See {authorization-book-link}#ref-rbac-permission-policies_title-authorization[Permission policies in {product}].
+Note that only {product-short} administrators or users with the `bulk.import` permission can use the Bulk Import feature.
+See {authorization-book-link}#ref-rbac-permission-policies_title-authorization[Permission policies in {product}].
 
 .Verification
 * The sidebar displays a *Bulk Import* option.
diff --git a/modules/importing-repositories/procedure-managing-the-imported-repository-list.adoc b/modules/importing-repositories/procedure-managing-the-imported-repository-list.adoc
@@ -1,5 +1,6 @@
 [id="managing-the-added-repositories"]
 = Managing the added repositories
+
 You can oversee and manage the repositories that are imported to the {product-short}.
 
 .Prerequisites
diff --git a/modules/installation/proc-deploy-rhdh-instance-gke.adoc b/modules/installation/proc-deploy-rhdh-instance-gke.adoc
@@ -1,19 +1,24 @@
 [id="proc-deploy-rhdh-instance-gke.adoc_{context}"]
 = Deploying the {product-short} instance on {gke-short} with the Operator
+
 You can deploy your {product-short} instance in {gke-short} using the Operator.
 
 .Prerequisites
 * A cluster administrator has installed the {product} Operator.
-* You have subscribed to `registry.redhat.io`. For more information, see link:https://access.redhat.com/articles/RegistryAuthentication[{company-name} Container Registry Authentication].
-* You have installed `kubectl`. For more information, see https://kubernetes.io/docs/tasks/tools/#kubectl[Install kubetl].
+* You have subscribed to `registry.redhat.io`.
+For more information, see link:https://access.redhat.com/articles/RegistryAuthentication[{company-name} Container Registry Authentication].
+* You have installed `kubectl`.
+For more information, see https://kubernetes.io/docs/tasks/tools/#kubectl[Install kubetl].
 
 * You have configured a domain name for your {product-short} instance.
-* You have reserved a static external Premium IPv4 Global IP address that is not attached to any virtual machine (VM). For more information see https://cloud.google.com/vpc/docs/reserve-static-external-ip-address#reserve_new_static[Reserve a new static external IP address]
+* You have reserved a static external Premium IPv4 Global IP address that is not attached to any virtual machine (VM).
+For more information see link:https://cloud.google.com/vpc/docs/reserve-static-external-ip-address#reserve_new_static[Reserve a new static external IP address]
 * You have configured the DNS records for your domain name to point to the IP address that has been reserved.
 +
 [NOTE]
 ====
-You need to create an `A` record with the value equal to the IP address. This process can take up to one hour to propagate.
+You need to create an `A` record with the value equal to the IP address.
+This process can take up to one hour to propagate.
 ====
 
 .Procedure
@@ -58,6 +63,7 @@ stringData:
   # TODO: See https://backstage.io/docs/auth/service-to-service-auth/#setup
   BACKEND_SECRET: "xxx"
 ----
+
 <1> `_<my_product_secrets>_` is your preferred {product-short} secret name, where `_<my_product_secrets>_` specifies the identifier for your secret configuration within {product-short}.
 
 [IMPORTANT]
@@ -108,6 +114,7 @@ spec:
       secrets:
         - name: `_<my_product_secrets>_` <1>
 ----
+
 <1> `_<my_product_secrets>_` is your preferred {product-short} secret name, where `_<my_product_secrets>_` specifies the identifier for your secret configuration within {product-short}.
 --
 
@@ -125,9 +132,11 @@ spec:
     - {my-product-domain}
 ----
 --
++
 For more information about setting up a Google-managed certificate, see https://cloud.google.com/kubernetes-engine/docs/how-to/managed-certs?hl=en#setting_up_a_google-managed_certificate[Setting up a Google-managed certificate].
 
-. Create a `FrontendConfig` object to set a policy for redirecting to HTTPS. You must attach this policy to the Ingress.
+. Create a `FrontendConfig` object to set a policy for redirecting to HTTPS.
+You must attach this policy to the Ingress.
 +
 --
 .Example of a `FrontendConfig` object
@@ -143,7 +152,8 @@ spec:
     enabled: true
 ----
 --
-For more information about setting a policy to redirect to HTTPS, see https://cloud.google.com/kubernetes-engine/docs/how-to/ingress-configuration?hl=en#https_redirect[HTTP to HTTPS redirects].
++
+For more information about setting a policy to redirect to HTTPS, see link:https://cloud.google.com/kubernetes-engine/docs/how-to/ingress-configuration?hl=en#https_redirect[HTTP to HTTPS redirects].
 
 . Create an ingress resource using the following template, customizing the names as needed:
 +
@@ -184,8 +194,8 @@ spec:
 
 
 .Verification
-
-* Wait for the `ManagedCertificate` to be provisioned. This process can take a couple of hours.
+* Wait for the `ManagedCertificate` to be provisioned.
+This process can take a couple of hours.
 
 * Access {product-very-short} with `pass:a,q[{my-product-url}]`.
 
diff --git a/modules/installation/proc-install-create-custom-flavor.adoc b/modules/installation/proc-install-create-custom-flavor.adoc
@@ -1,10 +1,12 @@
 [id='proc-install-create-custom-flavor_{context}']
 = Creating a custom flavor
-A custom flavor is a new operator profile with a specific directory structure. You can create a new flavor by following these steps:
 
-.Procedure
+A custom flavor is a new operator profile with a specific directory structure.
+You can create a new flavor by following these steps:
 
-. Create a dedicated directory for your flavor, following a standardized structure. This structure helps the operator identify and process all the components of your flavor:
+.Procedure
+. Create a dedicated directory for your flavor, following a standardized structure.
+This structure helps the operator identify and process all the components of your flavor:
 +
 [source,terminal,subs="+quotes"]
 ----
@@ -32,12 +34,14 @@ _kustomize.yaml_:: This is your flavor's manifest file that acts as the central
 
 _config/_:: Contains the core app-config.yaml for {product}, along with any plugin-specific configuration files.
 
-_resources/_:: Holds additional Kubernetes resources your flavor needs. This can include CRDs for dependencies or initial catalog entities to populate {product-very-short}.
+_resources/_:: Holds additional Kubernetes resources your flavor needs.
+This can include CRDs for dependencies or initial catalog entities to populate {product-very-short}.
 
 _hooks/_:: Contains manifests for Kubernetes jobs that run before (pre-install) or after (post-install) the {product-very-short} instance is deployed.
 
 . (Optional) If your flavor uses dynamic plugins that require specific Kubernetes resources, define these resources as YAML manifests in your `config/profile/{PROFILE}/plugin-deps` directory.
 
 . (Optional) For dependencies that require operators or other infrastructure, specify them in the _plugin-infra_ directory.
 
-. (Optional) Write Kubernetes job manifests for any pre-installation or post-installation tasks. The Operator will execute these jobs and monitor their status.
+. (Optional) Write Kubernetes job manifests for any pre-installation or post-installation tasks.
+The Operator will execute these jobs and monitor their status.
diff --git a/modules/installation/proc-install-distribute-custom-flavor.adoc b/modules/installation/proc-install-distribute-custom-flavor.adoc
@@ -1,10 +1,11 @@
 [id='proc-install-distribute-custom-flavor_{context}']
 = Distributing a custom flavor
+
 Custom flavors can be distributed as container images, offering a secure and versioned approach.
 
 .Procedure
-
-. Create a container image that contains your flavor's directory structure at a specific location, typically `/flavor/`. The image should be lightweight and contain only the necessary manifests and files.
+. Create a container image that contains your flavor's directory structure at a specific location, typically `/flavor/`.
+The image should be lightweight and contain only the necessary manifests and files.
 +
 [source,terminal,subs="+quotes"]
 ----
@@ -22,7 +23,9 @@ Custom flavors can be distributed as container images, offering a secure and ver
 podman push quay.io/myorg/my-custom-flavor:1.0.0
 ----
 
-. Users can deploy your custom flavor by referencing the container image directly in their Backstage custom resource. The operator pulls the image, extracts the contents, and applies the configuration automatically. For example:
+. Users can deploy your custom flavor by referencing the container image directly in their Backstage custom resource.
+The operator pulls the image, extracts the contents, and applies the configuration automatically.
+For example:
 +
 [source,yaml,subs="+attributes"]
 ----
@@ -34,4 +37,4 @@ spec:
   flavor:
     name: my-custom-flavor
     image: quay.io/myorg/my-custom-flavor:1.0.0
-----
+----
diff --git a/modules/installation/ref-install-flavor-schema.adoc b/modules/installation/ref-install-flavor-schema.adoc
