docs: Apply Markdown linting in Lifecycle Manager (#1603)

* Apply Markdown linting in Lifecycle Manager

* Fix the comments in markodownlint.yaml

.markdownlint.yaml

@@ -0,0 +1,31 @@
+# This is a configuration file for the markdownlint. You can use this file to overwrite the default settings.
+# MD004 checks if the asterisk symbol is used for unordered list items
+MD004:
+   style: asterisk
+# MD013 is set to false by default because many files include lines longer than the conventional 80 character limit
+MD013: false
+# MD024 disable the Multiple headings with the same content rule
+MD024: false
+# MD029 Set to false because it generates issues with longer lists
+MD029: false
+# MD033 is set to false to allow for inline HTML elements in a Markdown document
+MD033: false
+# MD044 is used to set capitalization for particular words. You can determine whether it should be used also for code blocks and HTML elements
+MD044:
+  code_blocks: false
+  html_elements: false
+  names:
+  - Kyma
+  - Kubernetes
+  - ConfigMap
+  - CronJob
+  - CustomResourceDefinition
+  - Ingress
+  - Node
+  - PodPreset
+  - Pod
+  - ProwJob
+  - Secret
+  - ServiceBinding
+  - ServiceClass
+  - ServiceInstance

docs/README.md

@@ -4,27 +4,27 @@
 
 The `docs` folder contains documentation on the Lifecycle Manager project.
 
-## Table of contents
+## Table of Contents
 
 The table of contents lists all the documents in repository with their short description.
 
-- [Developer tutorials](developer-tutorials/README.md) - a directory containing infrastructure-related guides for developers
-  - [Provide credential for private OCI registry authentication](developer-tutorials/config-private-registry.md)
-  - [Local test setup in the control-plane mode using k3d](developer-tutorials/local-test-setup.md)
-  - [Create a test environment on Google Container Registry (GCR)](developer-tutorials/prepare-gcr-registry.md)
-  - [Provision cluster and OCI registry](developer-tutorials/provision-cluster-and-registry.md)
-  - [Enable Webhooks in Lifecycle Manager](developer-tutorials/starting-operator-with-webhooks.md)
-- Technical reference - a directory with techncial details on Lifecycle Manager, such as architecture, APIs, or running modes
-  - [API](technical-reference/api/README.md) - a directory with the description of Lifecycle Manager's custom resources (CRs)
-    - [Kyma CR](technical-reference/api/kyma-cr.md)
-    - [Manifest CR](technical-reference/api/manifest-cr.md)
-    - [ModuleTemplate CR](technical-reference/api/moduleTemplate-cr.md)
-  - [Architecture](technical-reference/architecture.md) - describes Lifecycle Manager's architecture
-  - [Controllers](technical-reference/controllers.md) - describes Kyma, Manifest and Watcher controllers
-  - [Running Modes](technical-reference/running-modes.md) - describes Lifecycle Manager's running modes
-  - [Declarative Reconciliation Library Reference Documentation](/internal/declarative/README.md)
-  - [Internal Manifest Reconciliation Library Extensions](/internal/manifest/README.md)
-- User tutorials
-  - [Managing module enablement with the CustomResourcePolicy](user-tutorials/02-10-manage-module-with-custom-resource-policy.md)
-  - [Quick Start](user-tutorials/01-10-control-plane-quick-start.md)
-- [Modularization](modularization.md) - describes the modularization concept and its building blocks in the context of Lifecycle Manager
+* [Developer tutorials](developer-tutorials/README.md) - a directory containing infrastructure-related guides for developers
+  * [Provide credential for private OCI registry authentication](developer-tutorials/config-private-registry.md)
+  * [Local test setup in the control-plane mode using k3d](developer-tutorials/local-test-setup.md)
+  * [Create a test environment on Google Container Registry (GCR)](developer-tutorials/prepare-gcr-registry.md)
+  * [Provision cluster and OCI registry](developer-tutorials/provision-cluster-and-registry.md)
+  * [Enable Webhooks in Lifecycle Manager](developer-tutorials/starting-operator-with-webhooks.md)
+* Technical reference - a directory with techncial details on Lifecycle Manager, such as architecture, APIs, or running modes
+  * [API](technical-reference/api/README.md) - a directory with the description of Lifecycle Manager's custom resources (CRs)
+    * [Kyma CR](technical-reference/api/kyma-cr.md)
+    * [Manifest CR](technical-reference/api/manifest-cr.md)
+    * [ModuleTemplate CR](technical-reference/api/moduleTemplate-cr.md)
+  * [Architecture](technical-reference/architecture.md) - describes Lifecycle Manager's architecture
+  * [Controllers](technical-reference/controllers.md) - describes Kyma, Manifest and Watcher controllers
+  * [Running Modes](technical-reference/running-modes.md) - describes Lifecycle Manager's running modes
+  * [Declarative Reconciliation Library Reference Documentation](/internal/declarative/README.md)
+  * [Internal Manifest Reconciliation Library Extensions](/internal/manifest/README.md)
+* User tutorials
+  * [Managing module enablement with the CustomResourcePolicy](user-tutorials/02-10-manage-module-with-custom-resource-policy.md)
+  * [Quick Start](user-tutorials/01-10-control-plane-quick-start.md)
+* [Modularization](modularization.md) - describes the modularization concept and its building blocks in the context of Lifecycle Manager

docs/developer-tutorials/README.md

@@ -1,3 +1,3 @@
-# Developer tutorials
+# Developer Tutorials
 
 This directory contains infrastructure-related developer tutorials around Lifecycle Manager.

docs/developer-tutorials/config-private-registry.md

@@ -1,4 +1,4 @@
-# Provide credentials for private OCI registry authentication
+# Provide Credentials for Private OCI Registry Authentication
 
 ## Context
 
@@ -16,7 +16,7 @@ Before you proceed, prepare your registry credentials. Check also how to deal wi
 
 ## Procedure
 
-### Prepare a docker-registry Secret manifest
+### Prepare a docker-registry Secret Manifest
 
 1. Create a docker-registry Secret manifest. Run:
 
@@ -39,7 +39,7 @@ Before you proceed, prepare your registry credentials. Check also how to deal wi
 
 3. Deploy the Secret on the same cluster where the ModuleTemplate CR is to be located. For example, if the ModuleTemplate CR is on the SKR cluster, then the Secret should be deployed to the SKR. Otherwise, it should be deployed to the KCP cluster.
 
-### Generate a ModuleTemplate CR with the `oci-registry-cred` label
+### Generate a ModuleTemplate CR with the `oci-registry-cred` Label
 
 The `oci-registry-cred` label in a ModuleTemplate CR allows Lifecycle Manager to parse the Secret label selector and propagate it to the Manifest CR so that Lifecycle Manager knows which credentials Secret to look up.
 

docs/developer-tutorials/local-test-setup.md

@@ -1,26 +1,26 @@
-# Local test setup in the control-plane mode using k3d
+# Local test Setup in the control-plane Mode Using k3d
 
 ## Context
 
 This tutorial shows how to configure a fully working e2e test setup including the following components:
 
-- Lifecycle Manager
-- Runtime Watcher on a remote cluster
-- `template-operator` on a remote cluster as an example
+* Lifecycle Manager
+* Runtime Watcher on a remote cluster
+* `template-operator` on a remote cluster as an example
 
 This setup is deployed with the following security features enabled:
 
-- Strict mTLS connection between Kyma Control Plane (KCP) and SKR clusters
-- SAN Pinning (SAN of client TLS certificate needs to match the DNS annotation of a corresponding Kyma CR)
+* Strict mTLS connection between Kyma Control Plane (KCP) and SKR clusters
+* SAN Pinning (SAN of client TLS certificate needs to match the DNS annotation of a corresponding Kyma CR)
 
 > **NOTE:** If you want to use remote clusters instead of a local k3d setup or external registries, please refer to the following guides for the cluster and registry setup:
 >
-> - [Provision cluster and OCI registry](provision-cluster-and-registry.md)
-> - [Create a test environment on Google Container Registry (GCR)](prepare-gcr-registry.md)
+> * [Provision cluster and OCI registry](provision-cluster-and-registry.md)
+> * [Create a test environment on Google Container Registry (GCR)](prepare-gcr-registry.md)
 
 ## Procedure
 
-### KCP cluster setup
+### KCP Cluster Setup
 
 1. Create a local KCP cluster:
 
@@ -137,15 +137,15 @@ This setup is deployed with the following security features enabled:
    kubectl apply -f ./template.yaml
    ```
 
-### SKR cluster setup
+### SKR Cluster Setup
 
 Create a local Kyma runtime (SKR) cluster:
 
 ```shell
 k3d cluster create skr-local
 ```
 
-### Create a Kyma CR and a remote Secret
+### Create a Kyma CR and a Remote Secret
 
 1. Switch the context for using the KCP cluster:
 
@@ -216,7 +216,7 @@ k3d cluster create skr-local
 
    </details>
 
-### Watcher and module installation verification
+### Watcher and Module Installation Verification
 
 Check the Kyma CR events to verify if the `SKRWebhookIsReady` condition is set to `True`.
 Also make sure if the state of the `template-operator` is `Ready` and check the overall `state`.
@@ -257,7 +257,7 @@ status:
    state: Ready
 ```
 
-### (Optional) Check the functionality of the Watcher component
+### (Optional) Check the Functionality of the Watcher Component
 
 1. Switch the context to use the SKR cluster:
 

docs/developer-tutorials/prepare-gcr-registry.md

@@ -1,4 +1,4 @@
-# Create a test environment on Google Container Registry (GCR)
+# Create a test Environment on Google Container Registry (GCR)
 
 ## Context
 
@@ -10,7 +10,7 @@ This tutorial assumes that you have a GCP project called `sap-kyma-jellyfish-dev
 
 ## Procedure
 
-### Create your repository
+### Create your Repository
 
 1. Create an Artifact Registry repository. For tutorial purposes, call it `operator-test`.
 
@@ -27,7 +27,7 @@ This tutorial assumes that you have a GCP project called `sap-kyma-jellyfish-dev
     --location=europe-west3 --member=allUsers --role=roles/artifactregistry.reader
    ```
 
-### Authenticate locally and create a service account in Google Cloud
+### Authenticate Locally and Create a Service Account in Google Cloud
 
 1. Under the assumption you're [creating and using a service account](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/) called `operator-test-sa`, authenticate against your registry:
 

docs/developer-tutorials/provision-cluster-and-registry.md

@@ -1,4 +1,4 @@
-# Provision a cluster and OCI registry
+# Provision a Cluster and OCI Registry
 
 ## Context
 
@@ -8,7 +8,7 @@ For the control-plane mode, with Kyma Control Plane (KCP) and Kyma runtime (SKR)
 
 ## Procedure
 
-### Local cluster setup
+### Local Cluster Setup
 
 1. Create a `k3d` cluster:
 
@@ -31,14 +31,14 @@ For the control-plane mode, with Kyma Control Plane (KCP) and Kyma runtime (SKR)
 
 3. Set the `IMG` environment variable for the `docker-build` and `docker-push` commands, to make sure images are accessible by local k3d clusters.
 
-   - For the **single-cluster mode**:
+   * For the **single-cluster mode**:
 
       ```sh
       # pointing to KCP registry in dual cluster mode  
       export IMG=op-kcp-registry.localhost:8888/unsigned/operator-images
       ```
 
-   - For the **control-plane mode**:
+   * For the **control-plane mode**:
 
       ```sh
       # pointing to SKR registry in dual cluster mode
@@ -47,7 +47,7 @@ For the control-plane mode, with Kyma Control Plane (KCP) and Kyma runtime (SKR)
 
 4. Once you pushed your image, verify the content. For browsing through the content of the local container registry, use, for example, `http://op-kcp-registry.localhost:8888/v2/_catalog?n=100`.
 
-### Remote cluster setup
+### Remote Cluster Setup
 
 Learn how to use a Gardener cluster for testing.
 

docs/developer-tutorials/starting-operator-with-webhooks.md

@@ -1,4 +1,4 @@
-# Enable webhooks in Lifecycle Manager
+# Enable Webhooks in Lifecycle Manager
 
 ## Context
 

docs/technical-reference/api/README.md

@@ -14,21 +14,21 @@ Additionally, we maintain the [Watcher CR](/api/v1beta2/watcher_types.go) to def
 
 Read more about the custom resource definitions (CRDs) in the respective documents:
 
-- [Kyma CR](kyma-cr.md)
-- [Manifest CR](manifest-cr.md)
-- [ModuleTemplate CR](moduleTemplate-cr.md)
+* [Kyma CR](kyma-cr.md)
+* [Manifest CR](manifest-cr.md)
+* [ModuleTemplate CR](moduleTemplate-cr.md)
 
-## Synchronization of Module Catalog with remote clusters
+## Synchronization of Module Catalog with Remote Clusters
 
 Lifecycle Manager ensures the Module Catalog is correctly synchronized with users' runtimes.
 The Module Catalog consists of all modules, represented by ModuleTemplates CR, that are available for a user. The Module Catalog portfolio may vary for different users.
 The synchronization mechanism described below is essential to allow users to enable modules in their clusters.
 The mechanism is controlled by the set of labels that are configured on Kyma and ModuleTemplate CRs in the Control Plane. The labels are: `operator.kyma-project.io/sync`, `operator.kyma-project.io/internal`, and `operator.kyma-project.io/beta`.
 The v1beta2 API introduces three groups of modules:
 
-- Default modules, synchronized by default.
-- Internal modules, synchronized per-cluster only if configured explicitly on the corresponding Kyma CRs. To mark a ModuleTemplate CR as `internal`, use the `operator.kyma-project.io/internal` label and set it to `true`.
-- Beta modules, synchronized per-cluster only if configured explicitly on the corresponding Kyma CRs. To mark a ModuleTemplate CR as `beta`, use the `operator.kyma-project.io/beta` label and set it to `true`.
+* Default modules, synchronized by default.
+* Internal modules, synchronized per-cluster only if configured explicitly on the corresponding Kyma CRs. To mark a ModuleTemplate CR as `internal`, use the `operator.kyma-project.io/internal` label and set it to `true`.
+* Beta modules, synchronized per-cluster only if configured explicitly on the corresponding Kyma CRs. To mark a ModuleTemplate CR as `beta`, use the `operator.kyma-project.io/beta` label and set it to `true`.
 
 By default, without any labels configured on Kyma and ModuleTemplate CRs, a ModuleTemplate CR is synchronized with remote clusters.
 

docs/technical-reference/api/changelog.md

@@ -10,13 +10,13 @@ The v1beta1 to v1beta2 version change introduced the following changes to Lifecy
 
 The main change introduced to the Kyma CRD is the removal of the  **.spec.sync** attribute. As a result, the v1beta1 **.spec.sync** sub-attributes handling changes as described:
 
-- **.sync.enabled** - replaced by the `operator.kyma-project.io/sync` label in a Kyma CR. For details, read the [Kyma CR synchronization labels](link TBD) document.
-- **.sync.moduleCatalog** - replaced by a combination the `operator.kyma-project.io/sync`, `operator.kyma-project.io/internal`, and `operator.kyma-project.io/beta` labels in Kyma and ModuleTemplate CRs. For details, read the [Kyma CR synchronization labels](link TBD) document.
-- **.sync.namespace** - replaced with a `sync-namespace` command-line flag for Lifecycle Manager. It means that a user can no longer configure the Namespace synchronized with a particular Kyma CR. The Namespace is the same for all Kyma CRs in a given Lifecycle Manager instance, and a user can't change it.
-- **.sync.noModuleCopy** - removed. Currently, the **.spec.modules[]** for a remote Kyma CR is always initialized as empty.
+* **.sync.enabled** - replaced by the `operator.kyma-project.io/sync` label in a Kyma CR. For details, read the [Kyma CR synchronization labels](link TBD) document.
+* **.sync.moduleCatalog** - replaced by a combination the `operator.kyma-project.io/sync`, `operator.kyma-project.io/internal`, and `operator.kyma-project.io/beta` labels in Kyma and ModuleTemplate CRs. For details, read the [Kyma CR synchronization labels](link TBD) document.
+* **.sync.namespace** - replaced with a `sync-namespace` command-line flag for Lifecycle Manager. It means that a user can no longer configure the Namespace synchronized with a particular Kyma CR. The Namespace is the same for all Kyma CRs in a given Lifecycle Manager instance, and a user can't change it.
+* **.sync.noModuleCopy** - removed. Currently, the **.spec.modules[]** for a remote Kyma CR is always initialized as empty.
 
 ### ModuleTemplate CR
 
 In the ModuleTemplate CRD the changes relate to the **sync.target** attribute:
 
-- `.sync.target` - replaced with a `in-kcp-mode` command-line flag for Lifecycle Manager. It means that a user can no longer configure the ModuleTemplate synchronization. The configuration is the same for all ModuleTemplate CRs in a given Lifecycle Manager instance, and a user can't change it.
+* `.sync.target` - replaced with a `in-kcp-mode` command-line flag for Lifecycle Manager. It means that a user can no longer configure the ModuleTemplate synchronization. The configuration is the same for all ModuleTemplate CRs in a given Lifecycle Manager instance, and a user can't change it.