[bitnami/*] Fix markdown linter issues (bitnami#14874)

* [bitnami/*] Fix markdown linter issues

Signed-off-by: Carlos Rodríguez Hernández <[email protected]>

* Fix more issues

Signed-off-by: Carlos Rodríguez Hernández <[email protected]>

* Fix petetes

Signed-off-by: Carlos Rodríguez Hernández <[email protected]>

* Update README.md with readme-generator-for-helm

Signed-off-by: Bitnami Containers <[email protected]>

---------

Signed-off-by: Carlos Rodríguez Hernández <[email protected]>
Signed-off-by: Bitnami Containers <[email protected]>
Co-authored-by: Bitnami Containers <[email protected]>

.github/PULL_REQUEST_TEMPLATE.md

@@ -25,7 +25,7 @@
 ### Applicable issues
 
 <!-- Enter any applicable Issues here (You can reference an issue using #) -->
-  - fixes #
+- fixes #
 
 ### Additional information
 

CODE_OF_CONDUCT.md

@@ -12,6 +12,6 @@ If you are subjected to or witness unacceptable behavior, or have any other conc
 
 If you have suggestions to improve this Code of Conduct, please submit an issue or PR.
 
-**Attribution**
+## Attribution
 
-This Code of Conduct is adapted from the Angular project available at this page: https://github.com/angular/code-of-conduct/blob/master/CODE_OF_CONDUCT.md
+This Code of Conduct is adapted from the Angular project available at this page: <https://github.com/angular/code-of-conduct/blob/master/CODE_OF_CONDUCT.md>

CONTRIBUTING.md

@@ -14,6 +14,7 @@ Any type of contribution is welcome; from new features, bug fixes, [tests](#test
 ### Technical Requirements
 
 When submitting a PR make sure that it:
+
 - Must pass CI jobs for linting and test the changes on top of different k8s platforms. (Automatically done by the Bitnami CI/CD pipeline).
 - Must follow [Helm best practices](https://helm.sh/docs/chart_best_practices/).
 - Any change to a chart requires a version bump following [semver](https://semver.org/) principles. This is the version that is going to be merged in the GitHub repository, then our CI/CD system is going to publish in the Helm registry a new patch version including your changes and the latest images and dependencies.
@@ -32,14 +33,14 @@ If you set your `user.name` and `user.email` git configs, you can sign your comm
 
 Note: If your git config information is set properly then viewing the `git log` information for your commit will look something like this:
 
-```
-Author: Joe Smith <[email protected]>
-Date:   Thu Feb 2 11:41:15 2018 -0800
+    ```text
+    Author: Joe Smith <[email protected]>
+    Date:   Thu Feb 2 11:41:15 2018 -0800
 
-    Update README
+        Update README
 
-    Signed-off-by: Joe Smith <[email protected]>
-```
+        Signed-off-by: Joe Smith <[email protected]>
+    ```
 
 Notice the `Author` and `Signed-off-by` lines match. If they don't your PR will be rejected by the automated DCO check.
 
@@ -68,6 +69,7 @@ Notice the `Author` and `Signed-off-by` lines match. If they don't your PR will
 ### Adding a new chart to the repository
 
 There are three major technical requirements to add a new Helm chart to our catalog:
+
 - The chart should use Bitnami based container images. If they don't exist, you can [open a GitHub issue](https://github.com/bitnami/charts/issues/new/choose) and we will work together to create them.
 - Follow the same structure/patterns that the rest of the Bitnami charts (you can find a basic scaffolding in the [`template` directory](https://github.com/bitnami/charts/tree/main/template)) and the [Best Practices for Creating Production-Ready Helm charts](https://docs.bitnami.com/tutorials/production-ready-charts/) guide.
 - Use an [OSI approved license](https://opensource.org/licenses) for all the software.

README.md

@@ -8,9 +8,9 @@ Popular applications, provided by [Bitnami](https://bitnami.com), ready to launc
 ## TL;DR
 
 ```bash
-$ helm repo add bitnami https://charts.bitnami.com/bitnami
-$ helm search repo bitnami
-$ helm install my-release bitnami/<chart>
+helm repo add bitnami https://charts.bitnami.com/bitnami
+helm search repo bitnami
+helm install my-release bitnami/<chart>
 ```
 
 ![Installing a chart](demo.gif)
@@ -39,7 +39,6 @@ The quickest way to setup a Kubernetes cluster to install Bitnami Charts is foll
 - [Get Started with Bitnami Charts using the Azure Kubernetes Service (AKS)](https://docs.bitnami.com/kubernetes/get-started-aks/)
 - [Get Started with Bitnami Charts using the Amazon Elastic Container Service for Kubernetes (EKS)](https://docs.bitnami.com/kubernetes/get-started-eks/)
 - [Get Started with Bitnami Charts using the Google Kubernetes Engine (GKE)](https://docs.bitnami.com/kubernetes/get-started-gke/)
-- [Get Started with Bitnami Charts using the IBM Cloud Kubernetes Service (IKS)](https://docs.bitnami.com/kubernetes/get-started-charts-iks/)
 
 For setting up Kubernetes on other cloud platforms or bare-metal servers refer to the Kubernetes [getting started guide](https://kubernetes.io/docs/getting-started-guides/).
 
@@ -54,7 +53,7 @@ To install Helm, refer to the [Helm install guide](https://github.com/helm/helm#
 The following command allows you to download and install all the charts from this repository:
 
 ```bash
-$ helm repo add bitnami https://charts.bitnami.com/bitnami
+helm repo add bitnami https://charts.bitnami.com/bitnami
 ```
 
 > **_NOTE:_** It is important to note that the above mentioned repo is truncated so it only contains entries for the releases produced in the last 6 months. In case you need a full index, you can use it from the [archive-full-index branch](https://raw.githubusercontent.com/bitnami/charts/archive-full-index/bitnami/index.yaml) in the bitnami/charts Github repository.
@@ -70,9 +69,10 @@ Once you have installed the Helm client, you can deploy a Bitnami Helm Chart int
 Please refer to the [Quick Start guide](https://helm.sh/docs/intro/quickstart/) if you wish to get running in just a few commands, otherwise the [Using Helm Guide](https://helm.sh/docs/intro/using_helm/) provides detailed instructions on how to use the Helm client to manage packages on your Kubernetes cluster.
 
 Useful Helm Client Commands:
-* View available charts: `helm search repo`
-* Install a chart: `helm install my-release bitnami/<package-name>`
-* Upgrade your application: `helm upgrade`
+
+- View available charts: `helm search repo`
+- Install a chart: `helm install my-release bitnami/<package-name>`
+- Upgrade your application: `helm upgrade`
 
 ## License
 
@@ -82,7 +82,7 @@ Licensed under the Apache License, Version 2.0 (the "License"); you may not use
 
 You may obtain a copy of the License at
 
-    http://www.apache.org/licenses/LICENSE-2.0
+<http://www.apache.org/licenses/LICENSE-2.0>
 
 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 See the License for the specific language governing permissions and limitations under the License.

TESTING.md

@@ -20,16 +20,17 @@ In this section, we will discuss:
 * [Test types and tools](#test-types-and-tools)
 * [Generic acceptance criteria](#generic-acceptance-criteria)
 * [Cypress](#cypress)
-  * [Run it locally](#run-it-locally)
-  * [Useful information](#useful-information)
-  * [Specific acceptance criteria](#specific-acceptance-criteria)
+  * [Run Cypress locally](#run-cypress-locally)
+  * [Useful Cypress information](#useful-cypress-information)
+  * [Specific Cypress acceptance criteria](#specific-cypress-acceptance-criteria)
 * [Ginkgo](#ginkgo)
-  * [Run it locally](#run-it-locally-1)
-  * [Specific acceptance criteria](#specific-acceptance-criteria-1)
+  * [Run Ginkgo locally](#run-ginkgo-locally)
+  * [Useful Ginkgo information](#useful-ginkgo-information)
+  * [Specific Ginkgo acceptance criteria](#specific-ginkgo-acceptance-criteria)
 * [GOSS](#goss)
-  * [Run it locally](#run-it-locally-2)
-  * [Useful information](#useful-information-1)
-  * [Specific acceptance criteria](#specific-acceptance-criteria-2)
+  * [Run GOSS locally](#run-goss-locally)
+  * [Useful GOSS information](#useful-goss-information)
+  * [Specific GOSS acceptance criteria](#specific-goss-acceptance-criteria)
 
 ## Where to find the tests
 
@@ -123,10 +124,11 @@ Hence, tweaking the files allows to define different action policies depending o
 The general aim of the tests should be to verify the Chart package works as expected. As such, the focus IS NOT on the application OR the container images, which should be regarded as trustful components (i.e. they should have been respectively tested at a previous stage), but in the Chart itself and the different features it provides. It is expected though to assert the CORE functionality (or functionalities) of the application works, but checks defined in this repository should never aim to replace the official test suite.
 
 Some examples on the suitability of tests for the `bitnami/wordpress` chart:
- * ✅ Creating a blog post (represents the CORE functionality of the asset)
- * ❌ Creating a comment in a post (far too specific, not useful)
- * ❌ Installing a plugin through the admin panel (far too specific, not useful)
- * ✅ Specifying a different UID using the `containerSecurityContext.runAsUser` in `values.yaml` and checking it (checks a feature intrinsic to the Chart)
+
+* ✅ Creating a blog post (represents the CORE functionality of the asset)
+* ❌ Creating a comment in a post (far too specific, not useful)
+* ❌ Installing a plugin through the admin panel (far too specific, not useful)
+* ✅ Specifying a different UID using the `containerSecurityContext.runAsUser` in `values.yaml` and checking it (checks a feature intrinsic to the Chart)
 
 The tests may be regarded as _deployment_ tests since their goal is to verify that the software is correctly deployed with all the inherent features. Both functional and non-functional characteristics are evaluated in these tests, focusing on the installation aspect.
 
@@ -136,9 +138,9 @@ Before writing any test scenario, understand the primary purpose of the chart an
 
 As Charts are usually composed of a number of different components, it is also essential to test their integrations and the Chart as a whole. As a general guideline, testing a `bitnami/chart` can be reduced to:
 
-1. Identifying the components of the Chart and verifying their integration. *e.g. WordPress + MariaDB + PHP + Data Volume*
-1. Summarizing the main area features the asset offers and asserting the Chart delivers them. *e.g. Creating a post in a blog*
-1. Focusing on the unique features the Chart offers. *e.g. ConfigMaps, PVCs, Services, secrets, etc.*
+1. Identifying the components of the Chart and verifying their integration. _e.g. WordPress + MariaDB + PHP + Data Volume_
+1. Summarizing the main area features the asset offers and asserting the Chart delivers them. _e.g. Creating a post in a blog_
+1. Focusing on the unique features the Chart offers. _e.g. ConfigMaps, PVCs, Services, secrets, etc._
 
 It is easily noticeable though that Charts are usually highly configurable artifacts. Through parameters exposed in `values.yaml`, it is fairly common to perform customizations that range from enabling simple features (e.g. exporting metrics to Prometheus) to complete changes in the architecture of the application that will be deployed (e.g. standalone vs. main-secondary replication in DBs). In order to cope with this high variability, we should:
 
@@ -256,7 +258,7 @@ In order for VIB to execute Cypress tests, the following block of code needs to
 
 > ℹ️❗️ Cypress tests needs the UI to be accessible from outside the K8s testing cluster. This means (in most cases) that the service of the chart which exposes such UI should be set to use a `LoadBalancer` type and port `80` or `443`.
 
-### Run it locally
+### Run Cypress locally
 
 Sometimes it is of interest to run the tests locally, for example during development. Though there may be different approaches, you may follow the steps below to execute the tests locally:
 
@@ -333,7 +335,7 @@ Sometimes it is of interest to run the tests locally, for example during develop
     ✔  All specs passed!                        371ms        1        1
     ```
 
-### Useful information
+### Useful Cypress information
 
 * In most cases, a single test which covers the following topics is enough:
   * Login/Logout: Checks the UI, app, and DB are working together
@@ -343,7 +345,7 @@ Sometimes it is of interest to run the tests locally, for example during develop
 
 * If the asset exposes an API, Cypress is an excellent option to test this feature!
 
-### Specific acceptance criteria
+### Specific Cypress acceptance criteria
 
 * [ ] Test file name has the following format: Helm chart name + spec (ex: `wordpress_spec.js`)
 * [ ] No `describe()` blocks should be present
@@ -389,7 +391,7 @@ In order for VIB to execute Ginkgo tests, the following block of code needs to b
         }
 ```
 
-### Run it locally
+### Run Ginkgo locally
 
 Sometimes it is of interest to run the tests locally, for example during development. Though there may be different approaches, you may follow the steps below to execute the tests locally:
 
@@ -420,15 +422,15 @@ Sometimes it is of interest to run the tests locally, for example during develop
       Test Suite Passed
     ```
 
-### Useful information
+### Useful Ginkgo information
 
 Ginkgo provides extreme flexibility when it comes to tests. Nonetheless, here are the most frequent use cases we have used it for so far:
 
 * Checking logs produced by a scratch or a k8s-native pod
 * Deploying, managing and interacting with K8s resources: CRDs, Ingresses, Secrets... Really useful for **K8s operators**
 * Directly interacting (instead of managing) resources deployed at installation time using the `extraDeploy` param, available in bitnami charts
 
-### Specific acceptance criteria
+### Specific Ginkgo acceptance criteria
 
 * [ ] Test file name has the following format: Helm chart name + `test` (ex: `metallb_test.go`)
 * [ ] Helper functions should be placed in an additional file named `integration_suite_test.go`
@@ -457,21 +459,7 @@ In order for VIB to execute GOSS tests, the following block of code needs to be
         }
 ```
 
-### Useful information
-
-As our Charts implement some standardized properties, there are a number of test cases that have been found recurrently throughout the catalog:
-
-* Correct user ID and Group of the running container
-* Reachability of the different ports exposed through services
-* Existence of mounted volumes
-* Correct configuration was applied to a config file or enviroment variable
-* Existence of a created Service Account
-* Restricted capabilities are applied to a running container
-* Valuable CLI checks (when available)
-
-[Kong](https://github.com/bitnami/charts/blob/main/.vib/kong/goss/goss.yaml) or [MetalLB](https://github.com/bitnami/charts/blob/main/.vib/metallb/goss/goss.yaml) are two good examples of tests implementing some of the above.
-
-### Run it locally
+### Run GOSS locally
 
 Sometimes it is of interest to run the tests locally, for example during development. Though there may be different approaches, you may follow the steps below to execute the tests locally:
 
@@ -495,6 +483,7 @@ Sometimes it is of interest to run the tests locally, for example during develop
     $ kubectl cp .vib/nginx/goss/goss.yaml nginx-5fbc8786f-95rpl:/tmp/
     $ kubectl cp .vib/nginx/goss/vars.yaml nginx-5fbc8786f-95rpl:/tmp/
     ```
+
 1. Grant execution permissions to the binary and launch the tests
 
     ```bash
@@ -506,10 +495,24 @@ Sometimes it is of interest to run the tests locally, for example during develop
     Count: 9, Failed: 0, Skipped: 0
     ```
 
-### Specific acceptance criteria
+### Useful GOSS information
+
+As our Charts implement some standardized properties, there are a number of test cases that have been found recurrently throughout the catalog:
+
+* Correct user ID and Group of the running container
+* Reachability of the different ports exposed through services
+* Existence of mounted volumes
+* Correct configuration was applied to a config file or enviroment variable
+* Existence of a created Service Account
+* Restricted capabilities are applied to a running container
+* Valuable CLI checks (when available)
+
+[Kong](https://github.com/bitnami/charts/blob/main/.vib/kong/goss/goss.yaml) or [MetalLB](https://github.com/bitnami/charts/blob/main/.vib/metallb/goss/goss.yaml) are two good examples of tests implementing some of the above.
+
+### Specific GOSS acceptance criteria
 
 * [ ] Main test file name should be `goss.yaml`
 * [ ] Deployment-related parameters should be specified in a file named `vars.yaml`. This is a subset of the `runtime_parameters`
 * [ ] Use templating to parametrize tests with the help of the `vars.yaml` file
 * [ ] Tests should not rely on system packages (e.g. `curl`). Favor built-in GOSS primitives instead
-* [ ] Prefer checking the exit status of a command rather than looking for a specific output. This will avoid most of the potential flakiness
+* [ ] Prefer checking the exit status of a command rather than looking for a specific output. This will avoid most of the potential flakiness