Make adjustments

Author: GitHub Actions

modules/orchestrator/con-environment-variables-supported-by-the-build-script.adoc

@@ -3,26 +3,24 @@
 [id="con-environment-variables-supported-by-the-build-script.adoc_{context}"]
 = Environment variables supported by the build script
 
-The `build-sh` script supports the following environment variables to customize the workflow build process without modifying the script itself.
+The `build-sh` script supports the following environment variables to customize the workflow build process without modifying the script itself:
 
-* `QUARKUS_EXTENSIONS`
-
-The `QUARKUS_EXTENSIONS` variable specifies additional Quarkus extensions required by the workflow.
-
-This variable takes the format of a comma-separated list of fully qualified extension IDs as shown in the following example:
+`QUARKUS_EXTENSIONS`::
 
+The `QUARKUS_EXTENSIONS` variable specifies additional Quarkus extensions required by the workflow. This variable takes the format of a comma-separated list of fully qualified extension IDs as shown in the following example:
++
 [source,yaml]
 ----
 export QUARKUS_EXTENSIONS="io.quarkus:quarkus-smallrye-reactive-messaging-kafka"
 ----
-
++
 Add Kafka messaging support or other integrations at build time.
 
-* `MAVEN_ARGS_APPEND`
+`MAVEN_ARGS_APPEND`::
 
 The `MAVEN_ARGS_APPEND` variable appends additional arguments to the *Maven build* command.
 This variable takes the format of the string of Maven CLI arguments as shown in the following example:
-
++
 [source,yaml]
 ----
 export MAVEN_ARGS_APPEND="-DmaxYamlCodePoints=35000000"

modules/orchestrator/con-why-build-workflow-images.adoc

@@ -3,8 +3,9 @@
 [id="con-why-build-workflow-images.adoc_{context}"]
 = Why build workflow images?
 
-While the OpenShift Serverless Logic Operator supports the building of workflows dynamically, this approach is primarily for experimentation. For production deployments, building images is the preferred method due to the following reasons:
+While the OpenShift Serverless Logic Operator supports the building of workflows dynamically, this approach is primarily for experimentation.
+For production deployments, building images is the preferred method due to the following reasons:
 
-* Production readiness: Prebuilt images can be scanned, secured, and tested before going live.
-* GitOps compatibility: The Orchestrator relies on a central OpenShift Serverless Logic Operator instance to track workflows and their state. To use this tracking service, you must deploy workflows with the `gitops` profile, which expects a prebuilt image.
-* Testing & quality: Building an image gives you more control over the testing process.
+Production readiness:: Prebuilt images can be scanned, secured, and tested before going live.
+GitOps compatibility:: The Orchestrator relies on a central OpenShift Serverless Logic Operator instance to track workflows and their state. To use this tracking service, you must deploy workflows with the `gitops` profile, which expects a prebuilt image.
+Testing and quality:: Building an image gives you more control over the testing process.

modules/orchestrator/proc-building-locally.adoc

@@ -20,6 +20,7 @@ cd orchestrator-demo
 . Clone the project.
 
 . Check the help menu of the script:
++
 [source,yaml]
 ----
 ./scripts/build.sh --help

modules/orchestrator/proc-building-the-01-basic-workflow.adoc

@@ -17,7 +17,7 @@ To run the script from the root directory of the repository, you must use the `-
 ----
 ./scripts/build.sh --image=quay.io/orchestrator/demo-basic:test -w 01_basic/ -m 01_basic/manifests
 ----
-
++
 This build command produces the following two artifacts:
 
 * A workflow image and Kubernetes manifests: `quay.io/orchestrator/demo-basic:test` and tagged as `latest`.

modules/orchestrator/proc-deploying-workflows-on-a-cluster.adoc

@@ -14,7 +14,7 @@ You can now deploy the workflow on a cluster, since the image has been pushed to
 *   OpenShift Serverless `v1.36`
 *   OpenShift Serverless Logic `v1.36`
 
-For further instructions on installing these components, see the {orchestrator-book-link}#con-orchestrator-plugin-components[Orchestrator plugin components on {ocp-short}].
+For further instructions on installing these components, see the {orchestrator-book-link}#con-orchestrator-plugin-components.adoc_orchestrator-rhdh[Orchestrator plugin components on {ocp-short}].
 
 * You must apply the workflow manifests in a namespace that contains a `SonataflowPlatform` custom resource (CR), which manages the link:https://docs.redhat.com/en/documentation/red_hat_openshift_serverless/1.36/html-single/serverless_logic/index#serverless-logic-configuring-workflow-services[supporting services]. By default, OpenShift Serverless Logic services are installed in the `sonataflow-infra` namespace.