Remove whitespace at end of the line

docs/bundle-add.md

@@ -1,17 +1,17 @@
 # Create a Bundle Resource
 
 Bundles are automatically created by Fleet when a `GitRepo` is created. In most cases `Bundles` should not be created
-manually by the user. If you want to deploy resources from a git repository use a 
+manually by the user. If you want to deploy resources from a git repository use a
 [GitRepo](https://fleet.rancher.io/gitrepo-add) instead.
 
 If you want to deploy resources without a git repository follow this guide to create a `Bundle`.
 
-When creating a `GitRepo` Fleet will fetch the resources from a git repository, and add them to a Bundle. 
+When creating a `GitRepo` Fleet will fetch the resources from a git repository, and add them to a Bundle.
 When creating a `Bundle` resources need to be explicitly specified in the `Bundle` Spec.
-Resources can be compressed with gz. See [here](https://github.com/rancher/rancher/blob/v2.7.3/pkg/controllers/provisioningv2/managedchart/managedchart.go#L149-L153) 
+Resources can be compressed with gz. See [here](https://github.com/rancher/rancher/blob/v2.7.3/pkg/controllers/provisioningv2/managedchart/managedchart.go#L149-L153)
 an example of how Rancher uses compression in go code.
 
-If you would like to deploy in downstream clusters, you need to define targets. Targets work similarly to targets in `GitRepo`. 
+If you would like to deploy in downstream clusters, you need to define targets. Targets work similarly to targets in `GitRepo`.
 See [Mapping to Downstream Clusters](https://fleet.rancher.io/gitrepo-targets#defining-targets).
 
 The following example creates a nginx `Deployment` in the local cluster:
@@ -26,7 +26,7 @@ metadata:
   # your choosing
   namespace: fleet-local
 spec:
-  resources: 
+  resources:
   # List of all resources that will be deployed
   - content: |
       apiVersion: apps/v1
@@ -36,7 +36,7 @@ spec:
         labels:
           app: nginx
       spec:
-        replicas: 3 
+        replicas: 3
         selector:
           matchLabels:
             app: nginx

docs/bundle-diffs.md

@@ -54,16 +54,16 @@ In our case the differences detected are as follows:
         name: gatekeeper-controller-manager
         namespace: cattle-gatekeeper-system
         patch: '{"spec":{"template":{"spec":{"$setElementOrder/containers":[{"name":"manager"}],"containers":[{"name":"manager","resources":{"limits":{"cpu":"1000m"}}}],"tolerations":[]}}}}'
-```        
+```
 
 Based on this summary, there are three objects which need to be patched.
 
 We will look at these one at a time.
 
-### 1. ValidatingWebhookConfiguration: 
+### 1. ValidatingWebhookConfiguration:
-The gatekeeper-validating-webhook-configuration validating webhook has two ValidatingWebhooks in its spec. 
+The gatekeeper-validating-webhook-configuration validating webhook has two ValidatingWebhooks in its spec.
 
-In cases where more than one element in the field requires a patch, that patch will refer these to as `$setElementOrder/ELEMENTNAME` 
+In cases where more than one element in the field requires a patch, that patch will refer these to as `$setElementOrder/ELEMENTNAME`
 
 From this information, we can see the two ValidatingWebhooks in question are:
 
@@ -106,7 +106,7 @@ Within each ValidatingWebhook, the fields that need to be ignore are as follows:
     },
  ```
 
- and 
+ and
 
  ```
      {
@@ -151,9 +151,9 @@ Based on this information, our diff patch would look as follows:
     - {"op": "remove", "path":"/webhooks/0/rules"}
     - {"op": "remove", "path":"/webhooks/1/clientConfig/caBundle"}
     - {"op": "remove", "path":"/webhooks/1/rules"}
-```    
+```
 
-### 2. Deployment gatekeeper-controller-manager: 
+### 2. Deployment gatekeeper-controller-manager:
 The gatekeeper-controller-manager deployment is modified since there are cpu limits and tolerations applied (which are not in the actual bundle).
 
 ```

docs/cluster-bundles-state.md

@@ -22,7 +22,7 @@ Clusters and Bundles have different states in each phase of applying Bundles.
 
 **WaitCheckIn**: Waiting for agent to report registration information and cluster status back.
 
-**NotReady**: There are bundles in this cluster that are in NotReady state. 
+**NotReady**: There are bundles in this cluster that are in NotReady state.
 
 **WaitApplied**: There are bundles in this cluster that are in WaitApplied state.
 

docs/cluster-registration.md

@@ -14,7 +14,7 @@ manager initiated is a better workflow.
 
 ### Agent Initiated Registration
 
-Agent initiated refers to a pattern in which the downstream cluster installs an agent with a 
+Agent initiated refers to a pattern in which the downstream cluster installs an agent with a
 [cluster registration token](#create-cluster-registration-tokens) and optionally a client ID. The cluster
 agent will then make a API request to the Fleet manager and initiate the registration process. Using
 this process the Manager will never make an outbound API request to the downstream clusters and will thus
@@ -132,7 +132,7 @@ kubectl -n clusters get clusters.fleet.cattle.io
 ```
 ```
 NAME                   BUNDLES-READY   NODES-READY   SAMPLE-NODE             LAST-SEEN              STATUS
-cluster-ab13e54400f1   1/1             1/1           k3d-cluster2-server-0   2020-08-31T19:23:10Z   
+cluster-ab13e54400f1   1/1             1/1           k3d-cluster2-server-0   2020-08-31T19:23:10Z
 ```
 
 ### Install Agent For a Predefined Cluster
@@ -218,7 +218,7 @@ kubectl -n clusters get clusters.fleet.cattle.io
 ```
 ```
 NAME                   BUNDLES-READY   NODES-READY   SAMPLE-NODE             LAST-SEEN              STATUS
-my-cluster             1/1             1/1           k3d-cluster2-server-0   2020-08-31T19:23:10Z   
+my-cluster             1/1             1/1           k3d-cluster2-server-0   2020-08-31T19:23:10Z
 ```
 
 ### Create Cluster Registration Tokens

docs/concepts.md

@@ -42,7 +42,7 @@ Below are some of the concepts of Fleet that will be useful throughout this docu
 
 * **BundleDeployment**: When a `Bundle` is deployed to a cluster an instance of a `Bundle` is called a `BundleDeployment`.
     A `BundleDeployment` represents the state of that `Bundle` on a specific cluster with its cluster specific
-    customizations. The Fleet agent is only aware of `BundleDeployment` resources that are created for 
+    customizations. The Fleet agent is only aware of `BundleDeployment` resources that are created for
     the cluster the agent is managing.
 
     - For an example of how to deploy Kubernetes manifests across clusters using Fleet customization, click [here](./gitrepo-targets.md#customization-per-cluster).

docs/gitrepo-add.md

@@ -116,7 +116,7 @@ After secret is created, specify the secret to `gitRepo.spec.helmSecretName`. Ma
 
 Create a file `secrets-path.yaml` that contains credentials for each path defined in a `GitRepo`. Credentials will not be used
 for paths that are not present in this file.
-The path is the actual path to the bundle (ie to a folder containing a `fleet.yaml` file) within the git repository, which might have more segments than the entry under `paths:`. 
+The path is the actual path to the bundle (ie to a folder containing a `fleet.yaml` file) within the git repository, which might have more segments than the entry under `paths:`.
 
 Example:
 
@@ -136,7 +136,7 @@ Create the secret
 kubectl create secret generic path-auth-secret -n fleet-default --from-file=secrets-path.yaml
 ```
 
-In the previous example credentials for username `user` will be used for the path `path-one` and credentials for username 
+In the previous example credentials for username `user` will be used for the path `path-one` and credentials for username
 `user2` will be used for the path `path-two`.
 
 `caBundle` and `sshPrivateKey` must be base64 encoded.

docs/gitrepo-targets.md

@@ -93,9 +93,9 @@ The `targets:` in the `GitRepo` resource select clusters to deploy on. The `targ
 
 To demonstrate how to deploy Kubernetes manifests across different clusters with customization using Fleet, we will use [multi-cluster/helm/fleet.yaml](https://github.com/rancher/fleet-examples/blob/master/multi-cluster/helm/fleet.yaml).
 
-**Situation:** User has three clusters with three different labels: `env=dev`, `env=test`, and `env=prod`. User wants to deploy a frontend application with a backend database across these clusters. 
+**Situation:** User has three clusters with three different labels: `env=dev`, `env=test`, and `env=prod`. User wants to deploy a frontend application with a backend database across these clusters.
 
-**Expected behavior:** 
+**Expected behavior:**
 
 - After deploying to the `dev` cluster, database replication is not enabled.
 - After deploying to the `test` cluster, database replication is enabled.
@@ -107,7 +107,7 @@ Instead of deploying the app on each cluster, Fleet allows you to deploy across
 
 1. Deploy gitRepo `https://github.com/rancher/fleet-examples.git` and specify the path `multi-cluster/helm`.
 2. Under `multi-cluster/helm`, a Helm chart will deploy the frontend app service and backend database service.
-3. The following rule will be defined in `fleet.yaml`: 
+3. The following rule will be defined in `fleet.yaml`:
 
 ```
 targetCustomizations:

docs/imagescan.md

@@ -1,6 +1,6 @@
 # Using Image Scan to Update Container Image References
 
-Image scan in fleet allows you to scan your image repository, fetch the desired image and update your git repository, 
+Image scan in fleet allows you to scan your image repository, fetch the desired image and update your git repository,
 without the need to manually update your manifests.
 
 :::caution
@@ -13,28 +13,28 @@ Go to `fleet.yaml` and add the following section.
 
 ```yaml
 imageScans:
-# specify the policy to retrieve images, can be semver or alphabetical order 
+# specify the policy to retrieve images, can be semver or alphabetical order
-- policy: 
+- policy:
     # if range is specified, it will take the latest image according to semver order in the range
     # for more details on how to use semver, see https://github.com/Masterminds/semver
-    semver: 
+    semver:
-      range: "*" 
+      range: "*"
     # can use ascending or descending order
     alphabetical:
-      order: asc 
+      order: asc
 
   # specify images to scan
-  image: "your.registry.com/repo/image" 
+  image: "your.registry.com/repo/image"
 
   # Specify the tag name, it has to be unique in the same bundle
   tagName: test-scan
 
   # specify secret to pull image if in private registry
   secretRef:
-    name: dockerhub-secret 
+    name: dockerhub-secret
 
   # Specify the scan interval
-  interval: 5m 
+  interval: 5m
 ```
 
 :::info
@@ -99,11 +99,11 @@ metadata:
   namespace: fleet-local
 spec:
   # change this to be your own repo
-  repo: https://github.com/rancher/fleet-examples 
+  repo: https://github.com/rancher/fleet-examples
   # define how long it will sync all the images and decide to apply change
-  imageScanInterval: 5m 
+  imageScanInterval: 5m
   # user must properly provide a secret that have write access to git repository
-  clientSecretName: secret 
+  clientSecretName: secret
   # specify the commit pattern
   imageScanCommit:
     authorName: foo

docs/installation.md

@@ -7,7 +7,7 @@ import TabItem from '@theme/TabItem';
 
 The installation is broken up into two different use cases: single and multi-cluster.
 The single cluster install is for if you wish to use GitOps to manage a single cluster,
-in which case you do not need a centralized manager cluster. In the multi-cluster use case 
+in which case you do not need a centralized manager cluster. In the multi-cluster use case
 you will setup a centralized manager cluster to which you can register clusters.
 
 If you are just learning Fleet the single cluster install is the recommended starting
@@ -16,7 +16,7 @@ point. After which you can move from single cluster to multi-cluster setup down
 ![](/img/single-cluster.png)
 
 Single-cluster is the default installation. The same cluster will run both the Fleet
-manager and the Fleet agent. The cluster will communicate with Git server to 
+manager and the Fleet agent. The cluster will communicate with Git server to
 deploy resources to this local cluster. This is the simplest setup and very
 useful for dev/test and small scale setups.  This use case is supported as a valid
 use case for production.
@@ -77,7 +77,7 @@ You can now [register some git repos](./gitrepo-add.md) in the `fleet-local` nam
 :::caution
 Downstream clusters in Rancher are automatically registered in Fleet. Users can access Fleet under `Continuous Delivery` on Rancher.
 
-The multi-cluster install described below is **only** covered in standalone Fleet, which is untested by Rancher QA. 
+The multi-cluster install described below is **only** covered in standalone Fleet, which is untested by Rancher QA.
 :::
 
 
@@ -234,5 +234,5 @@ fleet-controller-64f49d756b-n57wq   1/1     Running   0          3m21s
 </TabItem>
 </Tabs>
 
-At this point the Fleet manager should be ready. You can now [register clusters](./cluster-registration.md) and [git repos](./gitrepo-add.md#create-gitrepo-instance) with 
+At this point the Fleet manager should be ready. You can now [register clusters](./cluster-registration.md) and [git repos](./gitrepo-add.md#create-gitrepo-instance) with
 the Fleet manager.

docs/ref-bundle.md

@@ -15,7 +15,7 @@ metadata:
   # your choosing
   namespace: fleet-local
 spec:
-  # Namespace used for resources that do not specify a namespace. 
+  # Namespace used for resources that do not specify a namespace.
   # This field is not used to enforce or lock down the deployment to a specific namespace.
   # defaultNamespace: test
 
@@ -25,30 +25,30 @@ spec:
 
   # Kustomize options for the deployment, like the dir containing the kustomization.yaml file.
   # kustomize: ...
-  
+
   # Helm options for the deployment, like the chart name, repo and values.
   # helm: ...
-  
+
   # ServiceAccount which will be used to perform this deployment.
   # serviceAccount: sa
 
   # ForceSyncGeneration is used to force a redeployment.
   # forceSyncGeneration: 0
-  
+
   # YAML options, if using raw YAML these are names that map to overlays/{name} that will be used to replace or patch a resource.
   # yaml: ...
-  
+
   # Diff can be used to ignore the modified state of objects which are amended at runtime.
   # A specific commit or tag can also be watched.
   #
   # diff: ...
-  
+
   # KeepResources can be used to keep the deployed resources when removing the bundle.
   # keepResources: false
-  
+
   # If set to true, will stop any BundleDeployments from being updated. It will be marked as out of sync.
   # paused: false
-  
+
   # Controls the rollout of bundles, by defining partitions, canaries and percentages for cluster availability.
   # rolloutStrategy: ...
 
@@ -62,7 +62,7 @@ spec:
         labels:
           app: nginx
       spec:
-        replicas: 3 
+        replicas: 3
         selector:
           matchLabels:
             app: nginx

docs/ref-configuration.md

@@ -24,8 +24,8 @@ In cluster configuration for the agent and fleet manager. Changing these can lea
 
 The config [struct](https://github.com/rancher/fleet/blob/master/pkg/config/config.go#L40-L52) is used in both config maps:
 
-* cattle-fleet-system/fleet-agent 
+* cattle-fleet-system/fleet-agent
-* cattle-fleet-system/fleet-controller 
+* cattle-fleet-system/fleet-controller
 
 ## Labels
 
@@ -62,5 +62,5 @@ Clusters. Default configuration will be used if these fields are not provided.
 
 If you change the resources limits, make sure the limits allow the fleet-agent to work normally.
 
-Keep in mind that if you downgrade Fleet to a previous version than v0.7.0 Fleet will fallback to the built-in defaults. 
+Keep in mind that if you downgrade Fleet to a previous version than v0.7.0 Fleet will fallback to the built-in defaults.
-Agents will redeploy if they had custom affinity. If Fleet version number does not change, redeployment might not be immediate.
+Agents will redeploy if they had custom affinity. If Fleet version number does not change, redeployment might not be immediate.

docs/ref-fleet-yaml.md

@@ -21,7 +21,7 @@ defaultNamespace: default
 # Default: ""
 namespace: default
 
-# Optional map of labels, that are set at the bundle and can be used in a 
+# Optional map of labels, that are set at the bundle and can be used in a
 # dependsOn.selector
 labels:
   key: value
@@ -83,7 +83,7 @@ helm:
   - configMapKeyRef:
       name: configmap-values
       # default to namespace of bundle
-      namespace: default 
+      namespace: default
       key: values.yaml
   - secretKeyRef:
       name: secret-values
@@ -98,7 +98,7 @@ helm:
   # if set and timeoutSeconds provided, will wait until all Jobs have been completed before marking the GitRepo as ready.
   # It will wait for as long as timeoutSeconds
   waitForJobs: true
-  
+
 # A paused bundle will not update downstream clusters but instead mark the bundle
 # as OutOfSync. One can then manually confirm that a bundle should be deployed to
 # the downstream clusters.
@@ -138,7 +138,7 @@ rolloutStrategy:
       # A cluster group name to include in this partition
       clusterGroup: agroup
       # Selector matching cluster group labels to include in this partition
-      clusterGroupSelector: 
+      clusterGroupSelector:
         clusterSelector:
           matchLabels:
             env: prod
@@ -174,8 +174,8 @@ targetCustomizations:
   clusterSelector:
     matchLabels:
       env: prod
-  # A selector used to match a specific cluster by name.    
+  # A selector used to match a specific cluster by name.
-  clusterName: dev-cluster    
+  clusterName: dev-cluster
   # A selector used to match cluster groups.
   clusterGroupSelector:
     matchLabels:
@@ -205,7 +205,7 @@ ignore:
   - type: Active
     status: "False"
 
-# Override targets defined in the GitRepo. The Bundle will not have any targets from the GitRepo if overrideTargets is provided. 
+# Override targets defined in the GitRepo. The Bundle will not have any targets from the GitRepo if overrideTargets is provided.
 overrideTargets:
   - clusterSelector:
       matchLabels:

docs/ref-gitrepo.md

@@ -49,10 +49,10 @@ spec:
   # this gitrepo. See section below for more information.
   #
   # helmSecretName: my-helm-secret
-  # 
+  #
-  # Helm credentials from helmSecretName will be used if the helm repository url matches this regular expression. 
+  # Helm credentials from helmSecretName will be used if the helm repository url matches this regular expression.
   # Credentials will always be used if it is empty or not provided
-  # 
+  #
   # helmRepoUrlRegex: https://charts.rancher.io/*
   #
   # To add additional ca-bundle for self-signed certs, caBundle can be

docs/troubleshooting.md

@@ -28,7 +28,7 @@ $ kubectl logs -l app=fleet-agent -n cattle-local-fleet-system
 
 Normally, errors should appear in the Rancher UI. However, if there is not enough information displayed about the error there, you can research further by trying one or more of the following as needed:
 
-- For more information about the bundle, click on `bundle`, and the YAML mode will be enabled. 
+- For more information about the bundle, click on `bundle`, and the YAML mode will be enabled.
 - For more information about the GitRepo, click on `GitRepo`, then click on `View Yaml` in the upper right of the screen. After viewing the YAML, check `status.conditions`; a detailed error message should be displayed here.
 - Check the `fleet-controller` for synching errors.
 - Check the `fleet-agent` log in the downstream cluster if you encounter issues when deploying the bundle.
@@ -55,7 +55,7 @@ Check the `gitjob-controller` logs using the following command with your specifi
 $ kubectl logs -f $gitjob-pod-name -n cattle-fleet-system
 ```
 
-Note that there are two containers inside the pod: the `step-git-source` container that clones the git repo, and the `fleet` container that applies bundles based on the git repo. 
+Note that there are two containers inside the pod: the `step-git-source` container that clones the git repo, and the `fleet` container that applies bundles based on the git repo.
 
 The pods will usually have images named `rancher/tekton-utils` with the `gitRepo` name as a prefix. Check the logs for these Kubernetes job pods in the local management cluster as follows, filling in your specific `gitRepoName` pod name and namespace:
 
@@ -81,8 +81,8 @@ fleet-controller-64f49d756b-n57wq   1/1     Running   0          3m21s
 
 Available in Rancher v2.6.3 (Fleet v0.3.8), the ability to enable debug logging has been added.
 
-- Go to the **Dashboard**, then click on the **local cluster** in the left navigation menu 
+- Go to the **Dashboard**, then click on the **local cluster** in the left navigation menu
-- Select **Apps & Marketplace**, then **Installed Apps** from the dropdown 
+- Select **Apps & Marketplace**, then **Installed Apps** from the dropdown
 - From there, you will upgrade the Fleet chart with the value `debug=true`. You can also set `debugLevel=5` if desired.
 
 ## **Additional Solutions for Other Fleet Issues**
@@ -121,7 +121,7 @@ Perform the following steps to assess:
 If your GitJob returns the error below, you may have added the wrong certificate chain:
 
 ```
-time="2021-11-11T05:55:08Z" level=fatal msg="Get \"https://helm.intra/virtual-helm/index.yaml\": x509: certificate signed by unknown authority" 
+time="2021-11-11T05:55:08Z" level=fatal msg="Get \"https://helm.intra/virtual-helm/index.yaml\": x509: certificate signed by unknown authority"
 ```
 
 Please verify your certificate with the following command:
@@ -147,13 +147,13 @@ To ignore the modified flag for the differences between the Helm install generat
 
 
 ```yaml
-defaultNamespace: <namespace name> 
+defaultNamespace: <namespace name>
-helm:  
+helm:
-  releaseName: <release name>  
+  releaseName: <release name>
-  repo: <repo name> 
+  repo: <repo name>
   chart: <chart name>
-diff:  
+diff:
-  comparePatches:  
+  comparePatches:
   - apiVersion: apps/v1
     kind: Deployment
     operations:
@@ -161,7 +161,7 @@ diff:
     - {"op":"remove", "path":"/spec/template/spec/nodeSelector"}
     jsonPointers: # jsonPointers allows to ignore diffs at certain json path
     - "/spec/template/spec/priorityClassName"
-    - "/spec/template/spec/tolerations" 
+    - "/spec/template/spec/tolerations"
 ```
 
 To determine which operations should be removed, observe the logs from `fleet-agent` on the target cluster. You should see entries similar to the following:
@@ -180,7 +180,7 @@ Based on the above log, you can add the following entry to remove the operation:
 
 **Modified** means that there is a mismatch between the actual state and the desired state, the source of truth, which lives in the git repository.
 
-1. Check the [bundle diffs documentation](./bundle-diffs.md) for more information. 
+1. Check the [bundle diffs documentation](./bundle-diffs.md) for more information.
 
 1. You can also force update the `gitrepo` to perform a manual resync. Select **GitRepo** on the left navigation bar, then select **Force Update**.
 

docs/tut-deployment.md

@@ -67,7 +67,7 @@ spec:
   repo: https://github.com/rancher/fleet-examples
   paths:
   - single-cluster/helm
-EOF  
+EOF
 ```
 
 </TabItem>
@@ -85,7 +85,7 @@ spec:
   repo: https://github.com/rancher/fleet-examples
   paths:
   - single-cluster/helm-multi-chart
-EOF  
+EOF
 ```
 
 </TabItem>
@@ -104,7 +104,7 @@ spec:
   repo: https://github.com/rancher/fleet-examples
   paths:
   - single-cluster/helm-kustomize
-EOF  
+EOF
 ```
 
 </TabItem>
@@ -118,7 +118,7 @@ Note that the `fleet.yaml` has a `kustomize:` key to specify the path to the req
 kustomize:
   # To use a kustomization.yaml different from the one in the root folder
   dir: ""
-```  
+```
 
 ```bash
 kubectl apply -n fleet-local -f - <<EOF
@@ -130,7 +130,7 @@ spec:
   repo: https://github.com/rancher/fleet-examples
   paths:
   - single-cluster/kustomize
-EOF  
+EOF
 ```
 
 </TabItem>
@@ -148,7 +148,7 @@ spec:
   repo: https://github.com/rancher/fleet-examples
   paths:
   - single-cluster/manifests
-EOF  
+EOF
 ```
 
 </TabItem>
@@ -221,7 +221,7 @@ spec:
   - name: prod
     clusterSelector:
       matchLabels:
-        env: prod  
+        env: prod
 ```
 
 By applying the gitrepo resource to the upstream cluster, fleet will start to monitor the repository and create deployments:
@@ -379,7 +379,7 @@ spec:
     clusterSelector:
       matchLabels:
         env: prod
-EOF  
+EOF
 ```
 
 By applying the gitrepo resource to the upstream cluster, fleet will start to monitor the repository and create deployments:
@@ -457,7 +457,7 @@ spec:
     clusterSelector:
       matchLabels:
         env: prod
-```        
+```
 
 <CodeBlock language="bash">
 {`kubectl apply -n fleet-default -f gitrepo.yaml`}