Fix broken docs link (#209)

Author: Nikolas De Giorgis

docs/architecture.md

@@ -12,23 +12,23 @@ The MongoDB Community Kubernetes Operator is a [Custom Resource Definition](http
 
 You create and update MongoDB resources by defining a MongoDB resource definition. When you apply the MongoDB resource definition to your Kubernetes environment, the Operator:
 
-1. Creates a [StatefulSet](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/) that contains one [pod](https://kubernetes.io/docs/concepts/workloads/pods/pod-overview/) for each [replica set](https://docs.mongodb.com/manual/replication/) member. 
-1. Writes the Automation configuration as a [ConfigMap](https://kubernetes.io/docs/concepts/configuration/configmap/) and mounts it to each pod. 
+1. Creates a [StatefulSet](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/) that contains one [pod](https://kubernetes.io/docs/concepts/workloads/pods/pod-overview/) for each [replica set](https://docs.mongodb.com/manual/replication/) member.
+1. Writes the Automation configuration as a [ConfigMap](https://kubernetes.io/docs/concepts/configuration/configmap/) and mounts it to each pod.
 1. Creates one [init container](https://kubernetes.io/docs/concepts/workloads/pods/init-containers/) and two [containers](https://kubernetes.io/docs/concepts/containers/overview/) in each pod:
 
    - An init container which copies the `cmd/versionhook` binary to the main `mongod` container. This is run before `mongod` starts to handle [version upgrades](#example-mongodb-version-upgrade).
 
    - A container for the [`mongod`](https://docs.mongodb.com/manual/reference/program/mongod/index.html) process binary. `mongod` is the primary daemon process for the MongoDB system. It handles data requests, manages data access, and performs background management operations.
 
-   - A container for the MongoDB Agent. The Automation function of the MongoDB Agent handles configuring, stopping, and restarting the `mongod` process. The MongoDB Agent periodically polls the `mongod` to determine status and can deploy changes as needed. 
-     
+   - A container for the MongoDB Agent. The Automation function of the MongoDB Agent handles configuring, stopping, and restarting the `mongod` process. The MongoDB Agent periodically polls the `mongod` to determine status and can deploy changes as needed.
+
 1. Creates several volumes:
 
    - `data-volume` which is [persistent](https://kubernetes.io/docs/concepts/storage/persistent-volumes/) and mounts to `/data` on both the server and agent containers. Stores server data as well as `automation-mongod.conf` written by the agent and some locks the agent needs.
    - `automation-config` which is mounted from the previously generated ConfigMap to both the server and agent. Only lives as long as the pod.
    - `healthstatus` which contains the agent's current status. This is shared with the `mongod` container where it's used by the pre-stop hook. Only lives as long as the pod.
-    
-1. Initiates the MongoDB Agent, which in turn creates the database configuration and launches the `mongod` process according to your [MongoDB resource definition](deploy/crds/mongodb.com_v1_mongodb_cr.yaml).
+
+1. Initiates the MongoDB Agent, which in turn creates the database configuration and launches the `mongod` process according to your [MongoDB resource definition](../deploy/crds/mongodb.com_v1_mongodb_cr.yaml).
 
 <!--
 <img src="" alt="Architecure diagram of the MongoDB Community Kubernetes Operator">
@@ -51,7 +51,7 @@ This architecture maximizes use of the MongoDB Agent while integrating naturally
 
 ## Example: MongoDB Version Upgrade
 
-The MongoDB Community Kubernetes Operator uses the Automation function of the MongoDB Agent to efficiently handle rolling upgrades. The Operator configures the StatefulSet to block Kubernetes from performing native rolling upgrades because the native process can trigger multiple re-elections in your MongoDB cluster. 
+The MongoDB Community Kubernetes Operator uses the Automation function of the MongoDB Agent to efficiently handle rolling upgrades. The Operator configures the StatefulSet to block Kubernetes from performing native rolling upgrades because the native process can trigger multiple re-elections in your MongoDB cluster.
 
 When you update the MongoDB version in your resource definition and reapply it to your Kubernetes environment, the Operator initiates a rolling upgrade:
 

docs/contributing.md

@@ -17,7 +17,7 @@ our local working environments in CI/CD systems.
 
 # High-Perspective Architecture
 
-The operator itself consists of 1 image, that has all the operational logic to deploy and 
+The operator itself consists of 1 image, that has all the operational logic to deploy and
 maintain the MongoDB resources in your cluster.
 
 The operator deploys MongoDB in Pods (via a higher-level resource, a
@@ -64,7 +64,7 @@ of this file.
 
 ## Configure Docker registry
 
-The build process consist in multiple Docker images being built, you need to specify 
+The build process consist in multiple Docker images being built, you need to specify
 where you want the locally build images to be pushed. The Docker registry needs to be
 accessible from your Kubernetes cluster.
 
@@ -128,9 +128,7 @@ MongoDB Replica Set and asserts that the deployed server can be connected to.
 # Writing new E2E tests
 
 You can start with `replica_set` test as an starting point to write a new test.
-The tests are written using `operator-sdk` and so you can find more information
-about how to write tests in the [official operator-sdk
-docs](https://sdk.operatorframework.io/docs/golang/legacy/e2e-tests/).
+The tests are written using `operator-sdk`.
 
 Adding a new test is as easy as to create a new directory in `test/e2e` with the
 new E2E test, and to run them:
@@ -144,11 +142,11 @@ python scripts/dev/e2e.py --test <new-test>
 ## Set up pre-commit hooks
 To set up the pre-commit hooks, please create symbolic links from the provided [hooks](https://github.com/mongodb/mongodb-kubernetes-operator/tree/master/scripts/git-hooks):
 
-* Navigate to your `.git/hooks` directory: 
+* Navigate to your `.git/hooks` directory:
 
 	`cd .git/hooks`
 
-* Create a symlink for every file in the `scripts/git-hooks` directory: 
+* Create a symlink for every file in the `scripts/git-hooks` directory:
 
 	`ln -s -f  ../../scripts/git-hooks/* .`
 

docs/deploy-configure.md

@@ -1,6 +1,6 @@
 # Deploy and Configure a MongoDB Resource #
 
-The [`/deploy/crds`](deploy/crds) directory contains example MongoDB resources that you can modify and deploy.
+The [`/deploy/crds`](../deploy/crds) directory contains example MongoDB resources that you can modify and deploy.
 
 ## Table of Contents
 
@@ -39,9 +39,9 @@ If you update `spec.version` to a later version, consider setting `spec.featureC
 
 If you want to deploy the operator on OpenShift you will have to provide the environment variable `MANAGED_SECURITY_CONTEXT` set to `true` for both the mongodb and mongodb agent containers, as well as the operator deployment.
 
-See [here](deploy/crds/mongodb.com_v1_mongodb_openshift_cr.yaml) for an example of how to provide the required configuration for a MongoDB ReplicaSet.
+See [here](../deploy/crds/mongodb.com_v1_mongodb_openshift_cr.yaml) for an example of how to provide the required configuration for a MongoDB ReplicaSet.
 
-See [here](deploy/operator_openshift.yaml) for an example of how to configure the Operator deployment.
+See [here](../deploy/operator_openshift.yaml) for an example of how to configure the Operator deployment.
 
 ### Example
 

docs/install-upgrade.md

@@ -32,7 +32,7 @@ To install the MongoDB Community Kubernetes Operator:
 
    a. Invoke the following `kubectl` command:
       ```
-      kubectl create -f deploy/crds/mongodb.com_mongodb_crd.yaml
+      kubectl create -f deploy/crds/mongodb.com_mongodb_scram_crd.yaml
       ```
    b. Verify that the Custom Resource Definitions installed successfully:
       ```

docs/users.md

@@ -1,6 +1,6 @@
 # Create a Database User #
 
-You can create a MongoDB database user to authenticate to your MongoDB resource using [SCRAM](https://docs.mongodb.com/manual/core/security-scram/). First, [create a Kubernetes secret](#create-a-user-secret) for the new user's password. Then, [modify and apply the MongoDB resource definition](#modify-the-mongodb-crd).
+You can create a MongoDB database user to authenticate to your MongoDB resource using [SCRAM](https://docs.mongodb.com/manual/core/security-scram/). First, [create a Kubernetes secret](#create-a-user-secret) for the new user's password. Then, [modify and apply the MongoDB resource definition](#modify-the-mongodb-resource).
 
 You cannot disable SCRAM authentication.
 
@@ -58,7 +58,7 @@ You cannot disable SCRAM authentication.
      users:
        - name: <username>
          db: <authentication-database>
-         passwordSecretRef: 
+         passwordSecretRef:
            name: <db-user-secret>
          roles:
            - name: <role-1>

scripts/git-hooks/pre-commit

@@ -41,8 +41,8 @@ function go_linting() {
     do
         dirs_to_analyze+=("$(dirname "${file}")" )
     done
-    mapfile -t dirs_to_analyze < <(printf '%s\n' "${dirs_to_analyze[@]}" | sort -u)
     if [ ${#dirs_to_analyze[@]} -ne 0 ]; then
+        mapfile -t dirs_to_analyze < <(printf '%s\n' "${dirs_to_analyze[@]}" | sort -u)
         echo "Running golangci-lint on staged files"
         local exit_status=0
         for file in "${dirs_to_analyze[@]}"