docs: surround embedded yaml files with backticks (keptn#2704)

Signed-off-by: Florian Bacher <florian.bacher@dynatrace.com>

docs-new/docs/components/scheduling.md

@@ -34,7 +34,9 @@ to wait for the Keptn checks before binding the pod to a node.
 
 For example, a pod gated by Keptn looks like the following:
 
+```yaml
 {% include "./assets/gated.yaml" %}
+```
 
 If the `pre-deployment` checks have finished successfully,
 the WorkloadVersion Controller removes the gate from the Pod.
@@ -45,7 +47,9 @@ When removing the gate,
 the WorkloadVersion controller also adds the following annotation so that,
 if the spec is updated, the Pod is not gated again:
 
+```yaml
 {% include "./assets/gate-removed.yaml" %}
+```
 
 ## Keptn Scheduler for K8s 1.26 and earlier
 
@@ -72,7 +76,9 @@ If the annotations are present, the Webhook assigns the **Keptn Scheduler** to t
 This ensures that the Keptn Scheduler only gets Pods that have been annotated for it.
 A Pod `test-pod` modified by the Mutating Webhook looks as follows:
 
+```yaml
 {% include "./assets/scheduler.yaml" %}
+```
 
 If the Pod is annotated with Keptn specific annotations, the Keptn Scheduler retrieves
 the WorkloadVersion CRD that is associated with the Pod.

docs-new/docs/guides/evaluations.md

@@ -8,7 +8,10 @@ meets a defined target value.
 The example
 [app-pre-deploy-eval.yaml](https://github.com/keptn/lifecycle-toolkit/blob/main/examples/sample-app/version-3/app-pre-deploy-eval.yaml)
 file specifies the `app-pre-deploy-eval-2` evaluation as follows:
+
+```yaml
 {% include "../assets/crd/eval.yaml" %}
+```
 
 The `evaluationTarget` is set to be `>1`,
 so this evaluation ensures that more than 1 CPU is available
@@ -20,7 +23,10 @@ that is named  `available-cpus`.
 This is defined in the example
 [metric.yaml](https://github.com/keptn/lifecycle-toolkit/blob/main/examples/sample-app/base/metric.yaml)
 file:
+
+```yaml
 {% include "../assets/crd/metric.yaml" %}
+```
 
 To run an evaluation on one of your
 [Workloads](https://kubernetes.io/docs/concepts/workloads/)

docs-new/docs/installation/index.md

@@ -227,7 +227,9 @@ If you wish to use your custom certificate manager,
 you can disable Keptn `cert-manager` by setting the
 `certificateManager.enabled` Helm value to `false`:
 
+```yaml
 {% include "./assets/values-remove-certmanager.yaml" %}
+```
 
 For more information on using `cert-manager` with Keptn, see
 [Use Keptn with cert-manager.io](../components/certificate-operator.md).

docs-new/docs/installation/tips-tricks.md

@@ -60,7 +60,9 @@ you do not need to install the Keptn Metrics Operator.
 To disable it, set the `metricsOperator.enabled` value
 to `false` as in the following:
 
+```yaml
 {% include "./assets/values-only-lifecycle.yaml" %}
+```
 
 Note that, if you want to run pre- and/or post-deployment
 [evaluations](../guides/evaluations.md)
@@ -106,7 +108,9 @@ If you are only interested in Metrics,
 you do not need the Keptn Lifecycle Operator.
 Disable it using the following values.yaml:
 
+```yaml
 {% include "./assets/values-only-metrics.yaml" %}
+```
 
 For more information about implementing Metrics, see the
 [Metrics User Guide](../guides/evaluatemetrics.md).
@@ -117,7 +121,9 @@ To enable Keptn Analysis in your cluster,
 you again do not need the Keptn Lifcycle Operator.
 Disable it using the following values.yaml:
 
+```yaml
 {% include "./assets/values-only-metrics.yaml" %}
+```
 
 > **Note** A preliminary release of the Keptn Analysis feature
   is included in Keptn v0.8.3 and v0.9.0 but is hidden behind a feature flag.
@@ -137,7 +143,9 @@ you can disable the Keptn `cert-manager` by using the
 to the `helm upgrade` command line
 or you can modify the `values.yaml` file:
 
+```yaml
 {% include "./assets/values-remove-certmanager.yaml" %}
+```
 
 For more information about using `cert-manager` with Keptn, see
 [Use Keptn with cert-manager.io](./configuration/cert-manager.md).

docs-new/docs/reference/crd-reference/analysis.md

@@ -305,7 +305,9 @@ kubectl get analysis - n keptn-lifecycle-poc -oyaml
 
 ## Examples
 
+```yaml
 {% include "../../assets/crd/analysis.yaml" %}
+```
 
 This `Analysis` resource:
 

docs-new/docs/reference/crd-reference/analysisvaluetemplate.md

@@ -80,7 +80,9 @@ The template refers to that provider and queries it.
 
 ## Example
 
+```yaml
 {% include "../../assets/crd/analysis-template.yaml" %}
+```
 
 For a full example of how the `AnalysisValueTemplate` is used
 to implement the Keptn Analysis feature, see the

docs-new/docs/reference/crd-reference/taskdefinition.md

@@ -378,7 +378,9 @@ For an example of a `KeptnTaskDefinition` that defines a custom container.
 This is a trivial example that just runs `busybox`,
 then spawns a shell and runs the `sleep 30` command:
 
+```yaml
 {% include "../../assets/crd/task-definition.yaml" %}
+```
 
 This task is then referenced in the
 [app.yaml](https://github.com/keptn/lifecycle-toolkit/blob/main/examples/sample-app/version-3/app.yaml)
@@ -514,7 +516,10 @@ data:
 
 You can embed python code directly in the task definition.
 This example prints data stored in the parameters map:
+
+```yaml
 {% include "../../assets/crd/python-inline.yaml" %}
+```
 
 ### Example 2: httpRef for a python-runtime runner
 
@@ -524,25 +529,35 @@ For example, we have a few examples available in the
 tree.
 
 Consider the following:
+
+```yaml
 {% include "../../assets/crd/python-configmap.yaml" %}
+```
 
 ### Example 3: functionRef for a python-runtime runner
 
 You can refer to an existing `KeptnTaskDefinition`.
 This example calls the inline example
 but overrides the data printed with what is specified in the task:
+
+```yaml
 {% include "../../assets/crd/python-recursive.yaml" %}
+```
 
 ### Example 4: ConfigMapRef for a python-runtime runner
 
+```yaml
 {% include "../../assets/crd/python-configmap.yaml" %}
+```
 
 ### Allowed libraries for the python-runtime runner
 
 The following example shows how to use some of the allowed packages, namely:
 requests, json, git, and yaml:
 
+```yaml
 {% include "../../assets/crd/python-libs.yaml" %}
+```
 
 ### Passing secrets, environment variables and modifying the python command
 
@@ -552,7 +567,9 @@ and how to modify the python command.
 In this case the container runs with the `-h` option,
 which prints the help message for the python3 interpreter:
 
+```yaml
 {% include "../../assets/crd/python-context.yaml" %}
+```
 
 ## More examples
 

docs-new/docs/use-cases/day-2-operations.md

@@ -42,7 +42,9 @@ let's assume the following example, including
 a [workload](https://kubernetes.io/docs/concepts/workloads/) called `podtato-head-frontend` that includes a pre-task and
 a pre-evaluation.
 
+```yaml
 {% include "./assets/deployment-initial.yaml" %}
+```
 
 Now, let's assume that the configuration of that [workload](https://kubernetes.io/docs/concepts/workloads/) needs to be changed.
 In this example we assume that the image of that [workload](https://kubernetes.io/docs/concepts/workloads/)
@@ -55,7 +57,9 @@ of the result of any task or evaluation, e.g., when the previously used image ha
 and the image must be updated as quickly as possible.
 To do that, change `podtato-head-frontend` as follows:
 
+```yaml
 {% include "./assets/deployment-new-image.yaml" %}
+```
 
 * **Update the configuration *and* the version label:**
 Doing so causes the `KeptnWorkload` that is associated
@@ -64,7 +68,9 @@ and therefore the pre-task `my-task` and pre-evaluation `my-evaluation`
 are executed before the updated pods are scheduled.
 In this case, the deployment should be changed as follows:
 
+```yaml
 {% include "./assets/deployment-new-image-and-version.yaml" %}
+```
 
 If you have defined the related `KeptnApp` resource yourself,
 this must also be updated to refer to the updated `KeptnWorkload`.
@@ -73,7 +79,9 @@ this updated deployment is not able to progress otherwise.
 Therefore, make sure that the version of `podtato-head-frontend`
 is updated accordingly:
 
+```yaml
 {% include "./assets/app-updated-version.yaml" %}
+```
 
 Updating the `KeptnApp` also causes all pre-/post-tasks/evaluations
 of the `KeptnApp` to be executed again.
@@ -129,7 +137,9 @@ For example, to add the deployment `podtato-head-left-leg` to the
 `podtato-head` application, the configuration for that new deployment
 would look like this, with the required label being set:
 
+```yaml
 {% include "./assets/new-deployment.yaml" %}
+```
 
 The `KeptnApp`, if defined by the user, should contain the
 reference to the newly added [workload](https://kubernetes.io/docs/concepts/workloads/).
@@ -138,7 +148,9 @@ progress if it is not part of a `KeptnApp`.
 For automatically discovered apps this is done
 automatically.
 
+```yaml
 {% include "./assets/app-with-new-workload.yaml" %}
+```
 
 After applying the updated manifests, you can monitor the status
 of the application and related [workloads](https://kubernetes.io/docs/concepts/workloads/) using the following commands:

docs-new/docs/use-cases/hpa.md

@@ -38,7 +38,9 @@ First, we need to deploy our application to the cluster.
 For this we are going to
 use a single service `podtato-head` application.
 
+```yaml
 {% include "./assets/hpa/sample-app.yaml" %}
+```
 
 Please create a `podtato-kubectl` namespace and apply the above manifest
 to your cluster and continue with the next steps.
@@ -57,7 +59,9 @@ These metrics are
 exposed via the custom metrics API, which gives us the possibility to configure
 the HPA to react on the values of these metrics:
 
+```yaml
 {% include "./assets/hpa/keptnmetric.yaml" %}
+```
 
 For more information about the `KeptnMetric` and `KeptnMetricsProvider` custom resources,
 please refer to the [CRD documentation](../reference/api-reference/metrics/v1beta1/index.md).
@@ -89,7 +93,9 @@ our cluster in the status of our `KeptnMetric` custom resource, we can configure
 a `HorizontalPodAutoscaler` to make use of this information and therefore scale
 our application automatically:
 
+```yaml
 {% include "./assets/hpa/hpa.yaml" %}
+```
 
 As we can see in this example, we are now referring to the `KeptnMetric`
 we applied earlier, and tell the HPA to scale up our application, until our