Enterprise version and doc QA checks

.github/md_config.json

@@ -0,0 +1,7 @@
+{
+  "ignorePatterns": [
+    {
+      "pattern": "^(?!http).+"
+    }
+  ]
+}

.github/workflows/pull_request.yaml

@@ -1,7 +1,7 @@
 name: Pull Request
 
 on:
-  pull_request_target:
+  pull_request:
     branches:
       - master
 
@@ -12,6 +12,12 @@ env:
   REGISTRY: ghcr.io
 
 jobs:
+  qa:
+    uses: stakater/.github/.github/workflows/pull_request_doc_qa.yaml@v0.0.43
+    with:
+      MD_CONFIG: .github/md_config.json
+      DOC_SRC: README.md docs
+      MD_LINT_CONFIG: .markdownlint.yaml
   build:
     runs-on: ubuntu-latest
     name: Build

.gitmodules

@@ -0,0 +1,3 @@
+[submodule "vocabulary"]
+	path = vocabulary
+	url = git@github.com:stakater/vocabulary.git

.markdownlint.yaml

@@ -0,0 +1,6 @@
+{
+  "MD007": { "indent": 4 },
+  "MD013": false,
+  "MD024": false,
+  "MD029": { "style": one },
+}

.vale.ini

@@ -0,0 +1,9 @@
+StylesPath = "vocabulary/styles"
+MinAlertLevel = warning
+
+Vocab = "Stakater"
+
+# Only check MarkDown files
+[*.md]
+
+BasedOnStyles = Vale

docs/Alerting.md

@@ -1,12 +1,18 @@
 # Alerting on Reload
-Reloader can alert when it triggers a rolling upgrade on Deployments or StatefulSets. Webhook notification alert would be sent to the configured webhook server with all the required information   
 
-#### Enabling the feature
-In-order to enable this feature, you need to update the reloader.env.secret section of values.yaml providing the information needed for alert. 
-<pre>      ALERT_ON_RELOAD: [ true/false ] Default: false 
+Reloader can alert when it triggers a rolling upgrade on Deployments or StatefulSets. Webhook notification alert would be sent to the configured webhook server with all the required information.
+
+## Enabling the feature
+
+In-order to enable this feature, you need to update the `reloader.env.secret` section of values.yaml providing the information needed for alert.
+
+```yaml
+      ALERT_ON_RELOAD: [ true/false ] Default: false 
       ALERT_SINK: [ slack/webhook ] Default: webhook
       ALERT_WEBHOOK_URL: Required if ALERT_ON_RELOAD is true
       ALERT_ADDITIONAL_INFO: Any additional information to be added to alert
+```
+
+## Slack incoming-webhook creation docs
 
-#### Slack incoming-webhook creation docs
-https://api.slack.com/messaging/webhooks 
+[Sending messages using Incoming Webhooks](https://api.slack.com/messaging/webhooks)

docs/Container Build.md

@@ -1,41 +1,53 @@
-
 # Container Build
-> **WARNING:** As a user of Reloader there is no need to build containers, these are freely available here: https://hub.docker.com/r/stakater/reloader/
 
-Multi-architecture approach is based on original work by @mdh02038: https://github.com/mdh02038/Reloader
+> **WARNING:** As a user of Reloader there is no need to build containers, the open source version is available on [Docker Hub](https://hub.docker.com/r/stakater/reloader/).
+
+Multi-architecture approach is based on original work by [@mdh02038](https://github.com/mdh02038/Reloader).
+
+Images are tested on linux/arm, linux/arm64 and linux/amd64.
 
-Images tested on linux/arm, linux/arm64 and linux/amd64.
+## Install Pre-Reqs
 
-# Install Pre-Reqs
-The build environment requires the following packages (tested on Ubuntu 20.04):
-* golang
-* make
-* qemu (for arm, arm64 etc. emulation)
+The build environment requires the following packages (tested on `Ubuntu 20.04`):
+
+* Golang
+* `make`
+* `qemu` (for arm, arm64 etc. emulation)
 * binfmt-support
 * Docker engine
 
 ## Docker
-Follow instructions here: https://docs.docker.com/engine/install/ubuntu/#install-using-the-repository
+
+Follow instructions on [Install using the apt repository](https://docs.docker.com/engine/install/ubuntu/#install-using-the-repository).
 
 Once installed, enable the experimental CLI:
-```
+
+```bash
 export DOCKER_CLI_EXPERIMENTAL=enabled
 ```
-Login, to enable publishing of packages:
-```
+
+Login to enable publishing of packages:
+
+```bash
 sudo docker login
 ```
+
 ## Remaining Pre-Reqs
+
 Remaining Pre-Reqs can be installed via:
-```
+
+```bash
 sudo apt install golang make qemu-user-static binfmt-support -y
 ```
 
-# Publish Multi-Architecture Image
+## Publish Multi-Architecture Image
+
 To build/ publish multi-arch Docker images clone repository and execute from repository root:
-```
+
+```bash
 sudo make release-all
 ```
 
-# Additional Links/ Info
-* *https://medium.com/@artur.klauser/building-multi-architecture-docker-images-with-buildx-27d80f7e2408
+## Additional Links/Info
+
+[Building Multi-Architecture Docker Images With `Buildx`](https://medium.com/@artur.klauser/building-multi-architecture-docker-images-with-buildx-27d80f7e2408)

docs/Helm2-to-Helm3.md

@@ -1,12 +1,13 @@
 # Helm2 to Helm3 Migration
 
-Follow below mentioned instructions to migrate reloader from Helm2 to Helm3
+Follow below mentioned instructions to migrate Reloader from Helm2 to Helm3
 
-## Instrcutions:
+## Instructions
 
-There are 3 steps involved in migrating the reloader from Helm2 to Helm3.
+There are 3 steps involved in migrating the Reloader from Helm2 to Helm3.
+
+### Step 1
 
-### Step 1:
 Install the helm-2to3 plugin
 
 ```bash
@@ -17,15 +18,18 @@ helm3 2to3 convert <release-name>
 helm3 2to3 cleanup --release-cleanup --skip-confirmation
 ```
 
-### Step 2:
-Add the following Helm3 labels and annotations on reloader resources.
+### Step 2
+
+Add the following Helm3 labels and annotations on Reloader resources.
 
 Label:
 
 ```yaml
 app.kubernetes.io/managed-by=Helm
 ```
+
 Annotations:
+
 ```yaml
 meta.helm.sh/release-name=<release-name>
 meta.helm.sh/release-namespace=<namespace>
@@ -51,12 +55,14 @@ kubectl annotate $KIND $NAME meta.helm.sh/release-namespace=$NAMESPACE
 kubectl label $KIND $NAME app.kubernetes.io/managed-by=Helm
 ```
 
-### Step 3:
+### Step 3
+
 Upgrade to desired version
+
 ```bash
 helm3 repo add stakater https://stakater.github.io/stakater-charts
 
 helm3 repo update
 
 helm3 upgrade <release-name> stakater/reloader --version=v0.0.72
-```
+```

docs/How-it-works.md

@@ -1,6 +1,6 @@
 # How it works?
 
-Reloader watches for `ConfigMap` and `Secret` and detects if there are changes in data of these objects. After change detection reloader performs rolling upgrade on relevant Pods via associated `Deployment`, `Daemonset` and `Statefulset`.
+Reloader watches for `ConfigMap` and `Secret` and detects if there are changes in data of these objects. After change detection Reloader performs rolling upgrade on relevant Pods via associated `Deployment`, `Daemonset` and `Statefulset`.
 
 ## How change detection works
 
@@ -13,37 +13,35 @@ To perform rolling upgrade a `deployment`, `daemonset` or `statefulset` must hav
 - support for rolling upgrade strategy
 - specific annotation for `configmaps` or `secrets`
 
-The annotation value is comma separated list of `configmaps` or `secrets`. If a change is detected in data of these `configmaps` or `secrets`, reloader will perform rolling upgrades on their associated `deployments`, `daemonsets` or `statefulsets`.
+The annotation value is comma separated list of `configmaps` or `secrets`. If a change is detected in data of these `configmaps` or `secrets`, Reloader will perform rolling upgrades on their associated `deployments`, `daemonsets` or `statefulsets`.
 
 ### Annotation for Configmap
 
-For a `Deployment` called `foo` have a `ConfigMap` called `foo`. Then add this annotation* to your `Deployment`
+For a `Deployment` called `foo` have a `ConfigMap` called `foo`. Then add this annotation* to your `Deployment`, where the default annotation can be changed with the `--configmap-annotation` flag:
 
 ```yaml
 metadata:
   annotations:
     configmap.reloader.stakater.com/reload: "foo"
 ```
-<small>*the default annotation can be changed with the `--configmap-annotation` flag</small>
 
 ### Annotation for Secret
 
-For a `Deployment` called `foo` have a `Secret` called `foo`. Then add this annotation* to your `Deployment`
+For a `Deployment` called `foo` have a `Secret` called `foo`. Then add this annotation to your `Deployment`, where the default annotation can be changed with the `--secret-annotation` flag:
 
 ```yaml
 metadata:
   annotations:
     secret.reloader.stakater.com/reload: "foo"
 ```
-<small>*the default annotation can be changed with the `--secret-annotation` flag</small>
 
 Above mentioned annotation are also work for `Daemonsets` `Statefulsets` and `Rollouts`
 
 ## How Rolling upgrade works?
 
-When reloader detects changes in configmap. It gets two objects of configmap. First object is an old configmap object which has a state before the latest change. Second object is new configmap object which contains latest changes. Reloader compares both objects and see whether any change in data occurred or not. If reloader finds any change in new configmap object, only then, it move forward with rolling upgrade.
+When Reloader detects changes in configmap. It gets two objects of configmap. First object is an old configmap object which has a state before the latest change. Second object is new configmap object which contains latest changes. Reloader compares both objects and see whether any change in data occurred or not. If Reloader finds any change in new configmap object, only then, it move forward with rolling upgrade.
 
-After that, reloader gets the list of all deployments, daemonsets and statefulset and looks for above mentioned annotation for configmap. If the annotation value contains the configmap name, it then looks for an environment variable which can contain the configmap or secret data change hash.
+After that, Reloader gets the list of all `deployments`, `daemonsets` and `statefulset` and looks for above mentioned annotation for configmap. If the annotation value contains the configmap name, it then looks for an environment variable which can contain the configmap or secret data change hash.
 
 ### Environment variable for Configmap
 
@@ -61,7 +59,7 @@ If Secret name is foo then
 STAKATER_FOO_SECRET
 ```
 
-If the environment variable is found then it gets its value and compares it with new configmap hash value. If old value in environment variable is different from new hash value then reloader updates the environment variable. If the environment variable does not exist then it creates a new environment variable with latest hash value from configmap and updates the relevant `deployment`, `daemonset` or `statefulset`
+If the environment variable is found then it gets its value and compares it with new configmap hash value. If old value in environment variable is different from new hash value then Reloader updates the environment variable. If the environment variable does not exist then it creates a new environment variable with latest hash value from configmap and updates the relevant `deployment`, `daemonset` or `statefulset`
 
 Note: Rolling upgrade also works in the same way for secrets.
 
@@ -71,12 +69,14 @@ Reloader uses SHA1 to compute hash value. SHA1 is used because it is efficient a
 
 ## Monitor All Namespaces
 
-By default reloader deploys in default namespace and monitors changes in all namespaces. To monitor changes in a specific namespace deploy the reloader in that namespace and set the `watchGlobally` flag to `false` in values file located under `deployments/kubernetes/chart/reloader`
-And render manifest file using helm command
+By default Reloader deploys in default namespace and monitors changes in all namespaces. To monitor changes in a specific namespace deploy the Reloader in that namespace and set the `watchGlobally` flag to `false` in values file located under `deployments/kubernetes/chart/reloader` and render manifest file using helm command:
+
 ```bash
 helm --namespace {replace this with namespace name} template . > reloader.yaml
 ```
-The output file can then be used to deploy reloader in specific namespace.
+
+The output file can then be used to deploy Reloader in specific namespace.
 
 ## Compatibility with helm install and upgrade
-Reloader has no impact on helm deployment cycle. Reloader only injects an environment variable in  `deployment`, `daemonset` or `statefulset`. The environment variable contains the SHA1 value of configmap's or secret's data. So  if a deployment is created using Helm and Reloader updates the deployment, then next time you upgrade the helm release, reloader will do nothing except changing that environment variable value in `deployment` , `daemonset` or `statefulset`.
+
+Reloader has no impact on helm deployment cycle. Reloader only injects an environment variable in  `deployment`, `daemonset` or `statefulset`. The environment variable contains the SHA1 value of configmap's or secret's data. So  if a deployment is created using Helm and Reloader updates the deployment, then next time you upgrade the helm release, Reloader will do nothing except changing that environment variable value in `deployment` , `daemonset` or `statefulset`.

docs/Reloader-vs-k8s-trigger-controller.md

@@ -5,36 +5,42 @@ Reloader and k8s-trigger-controller are both built for same purpose. So there ar
 ## Similarities
 
 - Both controllers support change detection in configmap and secrets
-- Both controllers support deployment rollout
+- Both controllers support deployment `rollout`
 - Both controllers use SHA1 for hashing
 - Both controllers have end to end as well as unit test cases.
 
 ## Differences
 
-### Support for Daemonsets and Statefulsets.
+### Support for `Daemonsets` and `Statefulsets`
 
-#### k8s-trigger-controller:
-k8s-trigger-controller only support for deployment rollout. It does not support daemonsets and statefulsets rollout.
+#### `k8s-trigger-controller`
 
-#### Reloader:
-Reloader supports deployment rollout as well as daemonsets and statefulsets rollout.
+`k8s-trigger-controller` only support for deployment `rollout`. It does not support `daemonsets` and `statefulsets` `rollout`.
+
+#### Reloader
+
+Reloader supports deployment `rollout` as well as `daemonsets` and `statefulsets` `rollout`.
 
 ### Hashing usage
 
-#### k8s-trigger-controller:
-k8s-trigger-controller stores the hash value in an annotation `trigger.k8s.io/[secret|configMap]-NAME-last-hash`
+#### `k8s-trigger-controller`
+
+`k8s-trigger-controller` stores the hash value in an annotation `trigger.k8s.io/[secret|configMap]-NAME-last-hash`
+
+#### Reloader
 
-#### Reloader:
 Reloader stores the hash value in an environment variable `STAKATER_NAME_[SECRET|CONFIGMAP]`
 
 ### Customization
 
-#### k8s-trigger-controller:
-k8s-trigger-controller restricts you to using the `trigger.k8s.io/[secret-configMap]-NAME-last-hash` annotation
+#### `k8s-trigger-controller`
+
+`k8s-trigger-controller` restricts you to using the `trigger.k8s.io/[secret-configMap]-NAME-last-hash` annotation
+
+#### Reloader
 
-#### Reloader:
 Reloader allows you to customize the annotation to fit your needs with command line flags:
 
 - `--auto-annotation <annotation>`
 - `--configmap-annotation <annotation>`
-- `--secret-annotation <annotation>`
+- `--secret-annotation <annotation>`

docs/Reloader-with-Sealed-Secrets.md

@@ -1,11 +1,14 @@
-Below are the steps to use reloader with Sealed Secrets.
-1. Download and install the kubeseal client from [here](https://github.com/bitnami-labs/sealed-secrets).
-2. Install the controller for sealed secrets
-3. Fetch the encryption certificate
-4. Encrypt the secret.
-5. Apply the secret.
-7. Install the tool which uses that sealed secret.
-8. Install Reloader.
-9. Once everything is setup, update the original secret at client and encrypt it with kubeseal to see reloader working.
-10. Apply the updated sealed secret.
-11. Reloader will restart the pod to use that updated secret.
+# Using Reloader with Sealed Secrets
+
+Below are the steps to use Reloader with Sealed Secrets:
+
+1. Download and install the kubeseal client from [here](https://github.com/bitnami-labs/sealed-secrets)
+1. Install the controller for sealed secrets
+1. Fetch the encryption certificate
+1. Encrypt the secret
+1. Apply the secret
+1. Install the tool which uses that sealed secret
+1. Install Reloader
+1. Once everything is setup, update the original secret at client and encrypt it with kubeseal to see Reloader working
+1. Apply the updated sealed secret
+1. Reloader will restart the pod to use that updated secret