Apply markdowlint rules in the serverless repository (#834)

.markdownlint.yaml

@@ -0,0 +1,26 @@
+# This is a configuration file for the markdownlint. You can use this file to overwrite the default settings.
+# MD013 is set to false by default because many files include lines longer than the conventional 80 character limit
+MD013: false
+# Disable the Multiple headings with the same content rule
+MD024: false
+# MD029 is set to false because it generated some issues with longer lists
+MD029: 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

.markdownlintignore

@@ -0,0 +1 @@
+_sidebar.md

docs/contributor/03-10-scripts-not-working.md

@@ -16,4 +16,4 @@ Install [Kyma CLI manually](https://github.com/kyma-project/cli#installation) an
 
    ```bash
    export KYMA=$(which kyma)
-   ```
+   ```

docs/contributor/04-10-testing-strategy.md

@@ -20,4 +20,4 @@ Each pull request to the repository triggers the following CI/CD jobs that verif
 
 ## CI/CD Jobs Running on a Schedule
 
-- `Markdown / link-check` - Runs Markdown link check every day at 05:00 AM.
+- `Markdown / link-check` - Runs Markdown link check every day at 05:00 AM.

docs/user/00-10-from-code-to-function.md

@@ -14,4 +14,4 @@ Functions support multiple languages by using the underlying execution environme
 You can also choose where you want to keep your Function's source code and dependencies. You can either place them directly in the Function CR under the **spec.source** and **spec.deps** fields as an **inline Function**, or store the code and dependencies in a public or private Git repository (**Git Functions**). Choosing the second option ensures your Function is versioned and gives you more development freedom in the choice of a project structure or an IDE.
 
 > [!TIP]
-> Read more about [Git Functions](technical-reference/07-40-git-source-type.md).
+> Read more about [Git Functions](technical-reference/07-40-git-source-type.md).

docs/user/00-20-configure-serverless.md

@@ -5,19 +5,20 @@
 The Serverless module has its own operator (Serverless operator). It watches the Serverless custom resource (CR) and reconfigures (reconciles) the Serverless workloads.
 
 The Serverless CR becomes an API to configure the Serverless module. You can use it to:
- - enable or disable the internal Docker registry
- - configure the external Docker registry 
- - override endpoint for traces collected by the Serverless Functions
- - override endpoint for eventing
- - override the target CPU utilization percentage
- - override the Function requeue duration
- - override the Function build executor arguments
- - override the Function build max simultaneous jobs
- - override the healthz liveness timeout
- - override the Function request body limit 
- - override the Function timeout
- - override the default build Job preset
- - override the default runtime Pod preset
+
+- enable or disable the internal Docker registry
+- configure the external Docker registry
+- override endpoint for traces collected by the Serverless Functions
+- override endpoint for eventing
+- override the target CPU utilization percentage
+- override the Function requeue duration
+- override the Function build executor arguments
+- override the Function build max simultaneous jobs
+- override the healthz liveness timeout
+- override the Function request body limit
+- override the Function timeout
+- override the default build Job preset
+- override the default runtime Pod preset
 
 The default configuration of the Serverless Module is following:
 
@@ -37,7 +38,7 @@ By default, Serverless uses PersistentVolume (PV) as the internal registry to st
 
 If you use Serverless for production purposes, it is recommended that you use an external registry, such as Docker Hub, Artifact Registry, or Azure Container Registry (ACR).
 
-Follow these steps to use the external Docker registry in Serverless: 
+Follow these steps to use the external Docker registry in Serverless:
 
 1. Create a Secret in the `kyma-system` namespace with the required data (`username`, `password`, `serverAddress`, and `registryAddress`):
 
@@ -71,6 +72,7 @@ Examples:
 ### **Artifact Registry**
 
 To learn how to set up authentication for Docker with Artifact Registry, visit the [Artifact Registry documentation](https://cloud.google.com/artifact-registry/docs/docker/authentication#json-key).
+
    ```bash
    kubectl create secret generic my-registry-config \
        --namespace kyma-system \
@@ -102,8 +104,8 @@ To learn how to authenticate with ACR, visit the [ACR documentation](https://lea
      dockerRegistry:
        secretName: my-registry-config 
    ```
-The URL of the currently used Docker registry is visible in the Serverless CR status.
 
+The URL of the currently used Docker registry is visible in the Serverless CR status.
 
 ## Configure Trace Endpoint
 
@@ -150,7 +152,8 @@ By default, the Function associated with the default configuration will be reque
 
 ## Configure the Function Build Executor Arguments
 
-Use this label to choose the [arguments](https://github.com/GoogleContainerTools/kaniko?tab=readme-ov-file#additional-flags) passed to the Function build executor, for example: 
+Use this label to choose the [arguments](https://github.com/GoogleContainerTools/kaniko?tab=readme-ov-file#additional-flags) passed to the Function build executor, for example:
+
 - `--insecure` - executor operates in an insecure mode
 - `--skip-tls-verify` - executor skips the TLS certificate verification
 - `--skip-unused-stages` - executor skips any stages that aren't used for the current execution
@@ -202,7 +205,7 @@ By default, the maximum execution time limit for a Function is set to `180` seco
 
 ## Configure the Default Build Job Preset
 
-You can configure the default build Job preset to be used. 
+You can configure the default build Job preset to be used.
 
 ```yaml
    spec:

docs/user/00-30-development-toolkit.md

@@ -7,7 +7,7 @@ To start developing your first Functions, you need:
 - [**Docker**](https://www.docker.com/) as the container runtime
 - [**kubectl**](https://kubernetes.io/docs/reference/kubectl/kubectl/), the Kubernetes command-line tool, for running commands against clusters
 - Development environment of your choice:
-   - **Kyma CLI** to easily initiate inline Functions or Git Functions locally, run, test, and later apply them in the clusters
-   - **Node.js** or **Python**
-   - **IDE** as the source code editor
-   - **Kyma dashboard** to manage Functions and related workloads through the graphical user interface
+  - **Kyma CLI** to easily initiate inline Functions or Git Functions locally, run, test, and later apply them in the clusters
+  - **Node.js** or **Python**
+  - **IDE** as the source code editor
+  - **Kyma dashboard** to manage Functions and related workloads through the graphical user interface

docs/user/00-40-security-considerations.md

@@ -16,4 +16,5 @@ To eliminate potential security risks when using Functions, bear in mind these f
 
   - Source code of all Functions within this namespace
   - Internal Docker registry that contains Function images
-  - Secrets allowing the build Job to pull and push images from and to the Docker registry (in non-system namespaces)
+  - Secrets allowing the build Job to pull and push images from and to the Docker registry (in non-system namespaces)
+

docs/user/00-50-limitations.md

@@ -1,23 +1,27 @@
 # Serverless Limitations
 
 ## Controller Limitations
+
 Serverless controller does not serve time-critical requests from users.
 It reconciles Function custom resources (CR), stored at the Kubernetes API Server, and has no persistent state on its own.
 
-Serverless controller doesn't build or serve Functions using its allocated runtime resources. It delegates this work to the dedicated Kubernetes workloads. It schedules (build-time) jobs to build the Function Docker image and (runtime) Pods to serve them once they are built. 
+Serverless controller doesn't build or serve Functions using its allocated runtime resources. It delegates this work to the dedicated Kubernetes workloads. It schedules (build-time) jobs to build the Function Docker image and (runtime) Pods to serve them once they are built.
 Refer to the [architecture](technical-reference/04-10-architecture.md) diagram for more details.
 
 Having this in mind Serverless Controller does not require horizontal scaling.
 It scales vertically up to the `160Mi` of memory and `500m` of CPU time.
 
 ## Limitation for the Number of Functions
-There is no upper limit of Functions that can be run on Kyma (similar to Kubernetes workloads in general). Once a user defines a Function, its build jobs and runtime Pods will always be requested by Serverless controller. It's up to Kubernetes to schedule them based on the available memory and CPU time on the Kubernetes worker nodes. This is determined mainly by the number of the Kubernetes worker nodes (and the node auto-scaling capabilities) and their computational capacity.
 
-## Build Phase Limitation:
+There is no upper limit of Functions that can be run on Kyma (similar to Kubernetes workloads in general). Once a user defines a Function, its build jobs and runtime Pods will always be requested by Serverless controller. It's up to Kubernetes to schedule them based on the available memory and CPU time on the Kubernetes worker nodes. This is determined mainly by the number of the Kubernetes worker nodes (and the Node auto-scaling capabilities) and their computational capacity.
+
+## Build Phase Limitation
+
 The time necessary to build Function depends on:
- - selected [build profile](technical-reference/07-80-available-presets.md#build-jobs-resources) that determines the requested resources (and their limits) for the build phase 
- - number and size of dependencies that must be downloaded and bundled into the Function image
- - cluster Nodes specification (see the note with reference specification at the end of this document)
+
+- selected [build profile](technical-reference/07-80-available-presets.md#build-jobs-resources) that determines the requested resources (and their limits) for the build phase
+- number and size of dependencies that must be downloaded and bundled into the Function image
+- cluster Nodes specification (see the note with reference specification at the end of this document)
 
 <!-- tabs:start -->
 
@@ -42,6 +46,7 @@ The shortest build time (the limit) is approximately 15 seconds and requires no
 Running multiple Function build jobs at once (especially with no limits) may drain the cluster resources. To mitigate such risk, there is an additional limit of 5 simultaneous Function builds. If a sixth one is scheduled, it is built once there is a vacancy in the build queue.
 
 ## Runtime Phase Limitations
+
 In the runtime, the Functions serve user-provided logic wrapped in the WEB framework (`express` for Node.js and `bottle` for Python). Taking the user logic aside, those frameworks have limitations and depend on the selected [runtime profile](technical-reference/07-80-available-presets.md#functions-resources) and the Kubernetes nodes specification (see the note with reference specification at the end of this document).
 
 The following describes the response times of the selected runtime profiles for a "Hello World" Function requested at 50 requests/second. This describes the overhead of the serving framework itself. Any user logic added on top of that will add extra milliseconds and must be profiled separately.
@@ -68,7 +73,6 @@ The following describes the response times of the selected runtime profiles for
 
 Obviously, the bigger the runtime profile, the more resources are available to serve the response quicker. Consider these limits of the serving layer as a baseline - as this does not take your Function logic into account.
 
-
 ### Scaling
 
 Function runtime Pods can be scaled horizontally from zero up to the limits of the available resources at the Kubernetes worker nodes.
@@ -78,5 +82,5 @@ See the [Use external scalers](tutorials/01-130-use-external-scalers.md) tutoria
 
 Serverless comes with an in-cluster Docker registry for the Function images. For more information on the Docker registry configuration, visit [Serverless configuration](00-20-configure-serverless.md#configure-docker-registry).
 
-> [!NOTE] 
-> All measurements were done on Kubernetes with five AWS worker nodes of type `m5.xlarge` (four CPU 3.1 GHz x86_64 cores, 16 GiB memory).
+> [!NOTE]
+> All measurements were done on Kubernetes with five AWS worker nodes of type `m5.xlarge` (four CPU 3.1 GHz x86_64 cores, 16 GiB memory).

docs/user/08-10-best-practices.md

@@ -5,7 +5,6 @@
 Kyma Serverless introduces a [Function](resources/06-10-function-cr.md) CustomResourceDefinition (CRD) as an extension to the Kubernetes API server.
 Defining a Function in Kyma essentially means creating a new instance of the Function custom resource (CR). However, the content of the Function CR specification may become quite long. It consists of the code (or Git reference to the code), dependencies, runtime specification, build-time specification, etc. Additionally, there are other CRs that are relevant for a Function developer - that is, [APIRule](https://kyma-project.io/docs/kyma/latest/05-technical-reference/00-custom-resources/apix-01-apirule/) (defining how Function is exposed to the outside world), [Subscription](https://kyma-project.io/docs/kyma/latest/05-technical-reference/00-custom-resources/evnt-01-subscription/) (defining which CloudEvents should trigger a Function), and others.
 
-
 All of that can be easily managed using the following best practices for the Function development. You will find recommendations that will be helpful for you at any stage of your development journey.
 
 ## Use UI to Explore
@@ -19,7 +18,7 @@ Get started with [Function UI](tutorials/01-10-create-inline-function.md)
 
 ## Use Kyma CLI for Better Development Experience
 
-Defining your Function from the Kyma dashboard is very quick and easy, but it might not be enough to satisfy your needs as a developer. To code and test more complex cases, you may want to write your Function in your favorite IDE or run and debug the Function on your local machine, before actually deploying in Kyma runtime. Also, you might want to avoid recreating the same Functions manually from the UI on a different environment. In the end, having deployable artifacts is more desirable. This is where Kyma CLI comes in handy, as it enables you to keep your Function's code and configuration in the form of a workspace. 
+Defining your Function from the Kyma dashboard is very quick and easy, but it might not be enough to satisfy your needs as a developer. To code and test more complex cases, you may want to write your Function in your favorite IDE or run and debug the Function on your local machine, before actually deploying in Kyma runtime. Also, you might want to avoid recreating the same Functions manually from the UI on a different environment. In the end, having deployable artifacts is more desirable. This is where Kyma CLI comes in handy, as it enables you to keep your Function's code and configuration in the form of a workspace.
 
 Initialize a scaffold for a brand new Function using the `kyma init function` command or fetch the current state of an existing Function deployed in your Kyma runtime using `kyma sync function`.
 Focus on the Function code and develop it from your favorite IDE. Configure your Functions directly in the [`config.yaml` manifest file](technical-reference/07-60-function-configuration-file.md)
@@ -36,10 +35,9 @@ Kyma CLI helps you run your code locally with a single `kyma run function` comma
 
 Having written and tested your Function locally, simply deploy it to the Kyma runtime with the `kyma apply function` command, used in the folder of your Function's workspace. The command reads the files, translates them to the Kubernetes manifests, and deploys the Function.
 
-
 ## Deploy Using CI/CD
 
-Kyma dashboard helps you get started. Kyma CLI helps you iterate and develop Functions. 
+Kyma dashboard helps you get started. Kyma CLI helps you iterate and develop Functions.
 But at the end of the day, you may want an automated deployment of your application, where Functions are just part of it.
 It all comes down to the deployment the Kubernetes applications on different Kyma runtimes in a GitOps fashion. For the sake of simplicity, the deployment approach for Functions should not differ from the deployment of the other Kubernetes workloads, ConfigMaps, or Secrets.
 
@@ -57,7 +55,7 @@ Deploy everything in a consistent way either using CI/CD or GitOps operators (fo
 
 > [!NOTE]
 > Kyma Functions come in two types: `git` and `inline`. For the [Git type](tutorials/01-11-create-git-function.md), you configure a Git repository as a source of your Function code instead of creating it `inline`.
-Thus, you can skip rendering the Kubernetes manifests and deploying them each time you made a change in the Function code or dependencies. Simply push the changes to the referenced Git repository, and the Serverless controller will rebuild the Function deployed in your Kyma runtime. 
+Thus, you can skip rendering the Kubernetes manifests and deploying them each time you made a change in the Function code or dependencies. Simply push the changes to the referenced Git repository, and the Serverless controller will rebuild the Function deployed in your Kyma runtime.
 
 Have a look at this [example](https://github.com/kyma-project/serverless/tree/main/examples/incluster_eventing) that illustrates how you can set up your Git project. Mind the `k8s resources` folder with the YAML manifests to be pushed to the Kubernetes API server (for example, using kubectl in our CI/CD or GitOps) and the `src` folder containing the Functions' source code. They are pulled directly by Kyma Serverless to build new Function images whenever the source content changes in the Git repository.  
 

docs/user/README.md

@@ -1,4 +1,4 @@
-# Serverless module
+# Serverless Module
 
 ## What is serverless?
 
@@ -24,20 +24,20 @@ Serverless in Kyma is an area that:
 
 Serverless in Kyma allows you to reduce the implementation and operation effort of an application to the absolute minimum. It provides a platform to run lightweight Functions in a cost-efficient and scalable way using JavaScript and Node.js. Serverless in Kyma relies on Kubernetes resources like [Deployments](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/), [Services](https://kubernetes.io/docs/concepts/services-networking/service/) and [HorizontalPodAutoscalers](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/) for deploying and managing Functions and [Kubernetes Jobs](https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/) for creating Docker images.
 
-## Serverless module
+## Serverless Module
 
 The Serverless module allows you to install, uninstall and configure Kyma's Serverless on your Kubernetes cluster, using Serverless Operator.
 
 ## Serverless Operator
 
 When you enable the Serverless module, Serverless Operator takes care of installation and configuration of Serverless on your cluster. It manages the Serverless lifecycle based on the dedicated Serverless custom resource (CR).
 
-## Useful links
+## Useful Links
 
 If you want to perform some simple and more advanced tasks, check the [Serverless tutorials](tutorials/README.md).
 
 To troubleshoot Serverless-related issues, see the [troubleshooting guides](troubleshooting-guides/README.md).
 
 To analyze Function specification and configuration files and to understand technicalities behind Serverless implementation, visit [technical reference](technical-reference/README.md).
 
-For more information on the Serverless custom resources, see [Resources](resources/README.md)
+For more information on the Serverless custom resources, see [Resources](resources/README.md).