[COSMETIC] Format fix

Author: amuraru

.github/actions/kind-create/action.yaml

@@ -46,12 +46,12 @@ runs:
       chmod 600 $kubeconfig_path
       echo "kubeconfig=$(echo $kubeconfig_path)" >> $GITHUB_OUTPUT
     shell: bash
-  
+
   - name: Install cloud-provider-kind
     id: cloud-provider-kind
     run: |
       echo "Install cloud-provider-kind"
       go install sigs.k8s.io/cloud-provider-kind@latest
-      kubectl label node e2e-kind-control-plane node.kubernetes.io/exclude-from-external-load-balancers- 
+      kubectl label node e2e-kind-control-plane node.kubernetes.io/exclude-from-external-load-balancers-
       ~/go/bin/cloud-provider-kind &
     shell: bash

.github/workflows/codeql-analysis.yml

@@ -60,17 +60,17 @@ jobs:
       run: |
         # Build main module
         go build ./...
-        
+
         # Build api module
         cd api
         go build ./...
         cd ..
-        
+
         # Build properties module
         cd properties
         go build ./...
         cd ..
-        
+
         # Build main binary
         go build -o bin/manager main.go
 

.github/workflows/e2e-test.yaml

@@ -87,3 +87,5 @@ jobs:
           # Clean any existing go.work files to avoid workspace conflicts
           rm -f go.work go.work.sum
           IMG_E2E=$REPOSITORY:$GITHUB_SHA make test-e2e
+
+

ADOPTERS.md

@@ -1,8 +1,8 @@
 # Adopters
  This is a list of production adopters of Banzai Cloud's Kafka Operator (in alphabetical order):
- 
+
 - Adobe Experience Platform is using the Kafka Operator to enable consistent deployment, dynamic scaling, smooth upgrades and auto-balancing in our cross-cloud Kafka infrastructure. Adobe is also contributing to the open source version of the operator.
 
 - [Banzai Cloud](https://banzaicloud.com) is using the Kafka Operator to provision, configure and manage a secure, resilient and autoscaling production ready Apache Kafka for customers.
 
-- AffirmedNetworks is looking to use Kafka Operator to provision, configure and manage life cycle of production ready Apache Kafka. One of the use cases we are looking at, is to use Kafka to manage Event Data/Detail Record that gets generated in our applications. 
+- AffirmedNetworks is looking to use Kafka Operator to provision, configure and manage life cycle of production ready Apache Kafka. One of the use cases we are looking at, is to use Kafka to manage Event Data/Detail Record that gets generated in our applications.

api/assets/kafka/kraft-controller-healthcheck.sh

@@ -33,7 +33,7 @@ MATCHING_METRIC=$(curl -s "$JMX_ENDPOINT" | grep "^${METRIC_PREFIX}" | awk '$2 =
 
 # If it's not empty, it means we found a metric with a value of 1.0.
 if [ -n "$MATCHING_METRIC" ]; then
-    # Determine the state of the controller using the last field name of the metric 
+    # Determine the state of the controller using the last field name of the metric
     # Possible values are leader, candidate, voted, follower, unattached, observer
     STATE=$(echo "$MATCHING_METRIC" | rev | cut -d'_' -f1 | rev)
 

docs/developer.md

@@ -37,4 +37,4 @@ Minikube does not have a load balancer implementation, thus our envoy service wi
 A possible solution to overcome this problem is to use https://github.com/elsonrodriguez/minikube-lb-patch. The operator will be able to proceed if you run the following command:
 ```go
 kubectl run minikube-lb-patch --replicas=1 --image=elsonrodriguez/minikube-lb-patch:0.1 --namespace=kube-system
-``` 
+```

third_party/github.com/banzaicloud/go-cruise-control/README.md

@@ -36,7 +36,7 @@ func main() {
 
 	// Create Context with timeout
 	ctx, cancel := context.WithTimeout(context.Background(), 30 * time.Second)
-	defer cancel() 
+	defer cancel()
 
 	// Optionally set request Reason to Context which will sent to Cruise Control as part of the HTTP request
 	ctx = client.ContextWithReason("example")

third_party/github.com/banzaicloud/go-cruise-control/deploy/producer/run.sh

@@ -25,7 +25,7 @@ create_topic() {
     --partitions 30 \
     --replication-factor 2 \
     --topic "${TOPIC}"
-  
+
   # Create the Cruise Control metrics topic
   /opt/kafka/bin/kafka-topics.sh \
     --bootstrap-server "${KAFKA_BROKERS}" \

third_party/github.com/banzaicloud/k8s-objectmatcher/README.md

@@ -16,7 +16,7 @@ There is a legacy version of the lib, that is now deprecated and documented here
 
 The library uses the same method that `kubectl apply` does under the hood to calculate a patch using the [three way merge](http://www.drdobbs.com/tools/three-way-merging-a-look-under-the-hood/240164902) method.
 However for this to work properly we need to keep track of the last applied version of our object, let's call it the `original`. Unfortunately Kubernetes does
-not keep track of our previously submitted object versions, but we can put it into an annotation like `kubectl apply` does. 
+not keep track of our previously submitted object versions, but we can put it into an annotation like `kubectl apply` does.
 Next time we query the `current` state of the object from the API Server we can extract the `original` version from the annotation.
 
 Once we have the the `original`, the `current` and our new `modified` object in place the library will take care of the rest.
@@ -72,7 +72,7 @@ Example:
 	opts := []patch.CalculateOption{
 		patch.IgnoreStatusFields(),
 	}
-	
+
 	patchResult, err := patch.DefaultPatchMaker.Calculate(existing.(runtime.Object), newObject.(runtime.Object), opts...)
 	if err != nil {
 		return err
@@ -89,7 +89,7 @@ This CalculateOption clears volumeClaimTemplate fields from both objects before
 
 #### IgnorePdbSelector
 
-Checks `selector` fields of PDB objects before comparing and removes them if they match. `reflect.DeepEquals` is used for the equality check. 
+Checks `selector` fields of PDB objects before comparing and removes them if they match. `reflect.DeepEquals` is used for the equality check.
 This is required because map fields using `patchStrategy:"replace"` will always diff regardless if they are otherwise equal.
 
 #### IgnoreField("field-name-to-ignore")

third_party/github.com/banzaicloud/k8s-objectmatcher/docs/legacy.md

@@ -33,11 +33,11 @@ objectMatcher.Match(e.ObjectOld, e.ObjectNew)
 
 ### The idea
 
-There are existing libraries in the wild that can calculate a patch by giving them two different objects. If the patch is empty the two objects match and we are ready, right? 
+There are existing libraries in the wild that can calculate a patch by giving them two different objects. If the patch is empty the two objects match and we are ready, right?
 Well not quite. JSON Merge Patch, defined by [rfc7396](https://tools.ietf.org/html/rfc7396) replaces lists completely which is not always what we need. Kubernetes defines
 and uses a modified version called [strategic merge patch](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-api-machinery/strategic-merge-patch.md).
 
-Strategic Merge Patch extends the JSON Merge Patch format by adding explicit directives for deleting, replacing, ordering and merging lists. 
+Strategic Merge Patch extends the JSON Merge Patch format by adding explicit directives for deleting, replacing, ordering and merging lists.
 It uses the go struct tag of the API objects to determine what lists should be merged and which ones should not. Worth to note it's not tied to
 Kubernetes objects only, so we can use this for matching custom go structs as well.
 
@@ -46,21 +46,21 @@ Kubernetes objects only, so we can use this for matching custom go structs as we
 #### Defaults and version compatibility
 
 As outlined previously Kubernetes objects are amended with different default values when submitted. For example PodSpec.RestartPolicy will be set to "Always" when
-ommitted from the object, so we will have a mismatch when we try to compare it later. This library uses the same functions to set the default values on the local 
-objects before matching so that they won't differ. 
+ommitted from the object, so we will have a mismatch when we try to compare it later. This library uses the same functions to set the default values on the local
+objects before matching so that they won't differ.
 
-Since the defaults functions are defined in the main kubernetes repo, there is a higher chance that objects decorated using these functions will be incompatible 
+Since the defaults functions are defined in the main kubernetes repo, there is a higher chance that objects decorated using these functions will be incompatible
 when comparing them with objects coming from different server versions. Also since the library depends on the kubernetes repo it is more tightly coupled to it's
 version.
 
-To preserve compatibility between the client and server versions  [.circleci/config.yml](.circleci/config.yml) contains jobs that run the integration test suite against Kubernetes 
+To preserve compatibility between the client and server versions  [.circleci/config.yml](.circleci/config.yml) contains jobs that run the integration test suite against Kubernetes
 versions from 1.10 to 1.14. The library itself is known and tested to be working with operators depending on Kubernetes client version 1.12 and 1.13.
 
 #### Generated values
 
-There are values that are generated by the API Server dynamically. To workaround this the library removes null fields from the patch as long as it's not inside a list. 
-(In case of lists, even if we remove null fields we would still left with `setElementOrder` directives) 
-This works as long as we don't set/unset complete fields on the objects conditionally, because in that case we would miss to detect a change to unset something. 
+There are values that are generated by the API Server dynamically. To workaround this the library removes null fields from the patch as long as it's not inside a list.
+(In case of lists, even if we remove null fields we would still left with `setElementOrder` directives)
+This works as long as we don't set/unset complete fields on the objects conditionally, because in that case we would miss to detect a change to unset something.
 
-In case a field gets removed from somewhere inside a list we have to explicitly tell to ignore it. One example is NodePort in Service objects, see [service.go](service.go). 
+In case a field gets removed from somewhere inside a list we have to explicitly tell to ignore it. One example is NodePort in Service objects, see [service.go](service.go).
 Another example is Volume and VolumeMount generated automatically for the service account token, see [pod.go](pod.go).