Fix typos

Dockerfile

@@ -21,14 +21,14 @@ RUN go mod download
 # Usage:
 #   docker buildx build --tag repo/img:tag -f ./Dockerfile . --platform linux/amd64,linux/arm64,linux/arm/v7
 #
-# With the above commmand,
+# With the above command,
 # TARGETOS can be "linux", TARGETARCH can be "amd64", "arm64", and "arm", TARGETVARIANT can be "v7".
 
 ARG TARGETPLATFORM TARGETOS TARGETARCH TARGETVARIANT VERSION=dev COMMIT_SHA=dev
 
 # We intentionally avoid `--mount=type=cache,mode=0777,target=/go/pkg/mod` in the `go mod download` and the `go build` runs
 # to avoid https://github.com/moby/buildkit/issues/2334
-# We can use docker layer cache so the build is fast enogh anyway
+# We can use docker layer cache so the build is fast enough anyway
 # We also use per-platform GOCACHE for the same reason.
 ENV GOCACHE /build/${TARGETPLATFORM}/root/.cache/go-build
 

apis/actions.summerwind.net/v1alpha1/runnerreplicaset_types.go

@@ -49,11 +49,11 @@ type RunnerReplicaSetStatus struct {
 	// +optional
 	Replicas *int `json:"replicas"`
 
-	// ReadyReplicas is the number of runners that are created and Runnning.
+	// ReadyReplicas is the number of runners that are created and Running.
 	ReadyReplicas *int `json:"readyReplicas"`
 
-	// AvailableReplicas is the number of runners that are created and Runnning.
-	// This is currently same as ReadyReplicas but perserved for future use.
+	// AvailableReplicas is the number of runners that are created and Running.
+	// This is currently same as ReadyReplicas but preserved for future use.
 	AvailableReplicas *int `json:"availableReplicas"`
 }
 

charts/actions-runner-controller/crds/actions.summerwind.dev_horizontalrunnerautoscalers.yaml

@@ -3,7 +3,7 @@ apiVersion: apiextensions.k8s.io/v1
 kind: CustomResourceDefinition
 metadata:
   annotations:
-    controller-gen.kubebuilder.io/version: v0.14.0
+    controller-gen.kubebuilder.io/version: v0.18.0
   name: horizontalrunnerautoscalers.actions.summerwind.dev
 spec:
   group: actions.summerwind.dev
@@ -159,10 +159,8 @@ spec:
                     ScaleUpTriggers is an experimental feature to increase the desired replicas by 1
                     on each webhook requested received by the webhookBasedAutoscaler.
 
-
                     This feature requires you to also enable and deploy the webhookBasedAutoscaler onto your cluster.
 
-
                     Note that the added runners remain until the next sync period at least,
                     and they may or may not be used by GitHub Actions depending on the timing.
                     They are intended to be used to gain "resource slack" immediately after you

cmd/ghalistener/worker/worker.go

@@ -221,7 +221,7 @@ func (w *Worker) HandleDesiredRunnerCount(ctx context.Context, count, jobsComple
 	return w.lastPatch, nil
 }
 
-// calculateDesiredState calculates the desired state of the worker based on the desired count and the the number of jobs completed.
+// calculateDesiredState calculates the desired state of the worker based on the desired count and the number of jobs completed.
 func (w *Worker) setDesiredWorkerState(count, jobsCompleted int) int {
 	// Max runners should always be set by the resource builder either to the configured value,
 	// or the maximum int32 (resourcebuilder.newAutoScalingListener()).

config/crd/bases/actions.summerwind.dev_horizontalrunnerautoscalers.yaml

@@ -3,7 +3,7 @@ apiVersion: apiextensions.k8s.io/v1
 kind: CustomResourceDefinition
 metadata:
   annotations:
-    controller-gen.kubebuilder.io/version: v0.14.0
+    controller-gen.kubebuilder.io/version: v0.18.0
   name: horizontalrunnerautoscalers.actions.summerwind.dev
 spec:
   group: actions.summerwind.dev
@@ -159,10 +159,8 @@ spec:
                     ScaleUpTriggers is an experimental feature to increase the desired replicas by 1
                     on each webhook requested received by the webhookBasedAutoscaler.
 
-
                     This feature requires you to also enable and deploy the webhookBasedAutoscaler onto your cluster.
 
-
                     Note that the added runners remain until the next sync period at least,
                     and they may or may not be used by GitHub Actions depending on the timing.
                     They are intended to be used to gain "resource slack" immediately after you