🌱 : fix traling spaces in the docs and add check as automate fix to the make generate

.github/workflows/spaces.yml

@@ -0,0 +1,22 @@
+name: Trailing
+
+# Trigger the workflow on pull requests and direct pushes to any branch
+on:
+  push:
+    paths:
+      - '**/*.md'
+  pull_request:
+    paths:
+      - '**/*.md'
+
+jobs:
+  lint:
+    name: "Check Trailing"
+    runs-on: ubuntu-latest
+    # Pull requests from the same repository won't trigger this checks as they were already triggered by the push
+    if: (github.event_name == 'push' || github.event.pull_request.head.repo.full_name != github.repository)
+    steps:
+      - name: Clone the code
+        uses: actions/checkout@v4
+      - name: Run check
+        run: make test-spaces

Makefile

@@ -66,6 +66,12 @@ install: build ## Build and install the binary with the current source code. Use
 .PHONY: generate
 generate: generate-testdata generate-docs ## Update/generate all mock data. You should run this commands to update the mock data after your changes.
 	go mod tidy
+	remove-spaces
+
+.PHONY: remove-spaces
+remove-spaces:
+	@echo "Removing trailing spaces"
+	@find . -type f -name "*.md" -exec sed -i '' 's/[[:space:]]*$$//' {} +
 
 .PHONY: generate-testdata
 generate-testdata: ## Update/generate the testdata in $GOPATH/src/sigs.k8s.io/kubebuilder
@@ -160,3 +166,7 @@ test-book: ## Run the cronjob tutorial's unit tests to make sure we don't break
 .PHONY: test-license
 test-license:  ## Run the license check
 	./test/check-license.sh
+
+.PHONY: test-spaces
+test-spaces:  ## Run the trailing spaces check
+	./test/check_spaces.sh

README.md

@@ -23,10 +23,10 @@ Kubebuilder is developed on top of the [controller-runtime][controller-runtime]
 ### Kubebuilder is also a library
 
 Kubebuilder is extensible and can be used as a library in other projects.
-[Operator-SDK][operator-sdk] is a good example of a project that uses Kubebuilder as a library. 
+[Operator-SDK][operator-sdk] is a good example of a project that uses Kubebuilder as a library.
 [Operator-SDK][operator-sdk] uses the plugin feature to include non-Go operators _e.g. operator-sdk's Ansible and Helm-based language Operators_.
 
-To learn more see [how to create your own plugins][your-own-plugins]. 
+To learn more see [how to create your own plugins][your-own-plugins].
 
 ### Installation
 
@@ -39,9 +39,9 @@ See the [Getting Started](https://book.kubebuilder.io/quick-start.html) document
 
 ![Quick Start](docs/gif/kb-demo.v3.11.1.svg)
 
-Also, ensure that you check out the [Deploy Image](https://book.kubebuilder.io/plugins/deploy-image-plugin-v1-alpha.html) 
-Plugin. This plugin allows users to scaffold API/Controllers to deploy and manage an 
-Operand (image) on the cluster following the guidelines and best practices. It abstracts the 
+Also, ensure that you check out the [Deploy Image](https://book.kubebuilder.io/plugins/deploy-image-plugin-v1-alpha.html)
+Plugin. This plugin allows users to scaffold API/Controllers to deploy and manage an
+Operand (image) on the cluster following the guidelines and best practices. It abstracts the
 complexities of achieving this goal while allowing users to customize the generated code.
 
 ## Documentation
@@ -121,18 +121,18 @@ Before starting any work, please either comment on an existing issue, or file a
 
 ## Supportability
 
-Currently, Kubebuilder officially supports OSX and Linux platforms. 
-So, if you are using a Windows OS you may find issues. Contributions towards 
+Currently, Kubebuilder officially supports OSX and Linux platforms.
+So, if you are using a Windows OS you may find issues. Contributions towards
 supporting Windows are welcome.
 
 ### Apple Silicon
 
 Apple Silicon (`darwin/arm64`) support begins with the `go/v4` plugin.
 
 ## Community Meetings
- 
+
 The following meetings happen biweekly:
-  
+
 - Kubebuilder Meeting
 
 You are more than welcome to attend. For further info join to [kubebuilder@googlegroups.com](https://groups.google.com/g/kubebuilder).

RELEASE.md

@@ -25,14 +25,14 @@ process was done to ensure that we have an aligned process under the org (simila
 > **Note**
 > - You will need to have checkout locally from the remote repository the previous branch
 > - Also, ensure that you fetch all tags from the remote `git fetch --all --tags`
-> - Also, if you face issues to generate the release notes you might want to able to sort it out by running i.e.: 
+> - Also, if you face issues to generate the release notes you might want to able to sort it out by running i.e.:
 > `go run sigs.k8s.io/kubebuilder-release-tools/notes --use-upstream=false --from=v3.11.0 --branch=release-X`
 
 
 ### Draft a new release from GitHub
 
 1. Create a new tag with the correct version from the new `release-<MAJOR.MINOR>` branch
-2. Verify the Release Github Action. It should build the assets and publish in the draft release 
+2. Verify the Release Github Action. It should build the assets and publish in the draft release
 3. You also need to manually add the changelog generated above on the release page and publish it. Now, the code source is released !
 
 ### Update the website docs (https://book.kubebuilder.io/quick-start.html)
@@ -75,7 +75,7 @@ This action will caall the job [./build/.goreleaser.yml](./build/.goreleaser.yml
 Kubebuilder projects requires artifacts which are used to do test with ENV TEST (when we call `make test` target)
 These artifacts can be checked in the service page: https://storage.googleapis.com/kubebuilder-tools
 
-The build is made from the branch [tools-releases](https://github.com/kubernetes-sigs/kubebuilder/tree/tools-releases) and the trigger will call the `build/cloudbuild_tools.yaml` passing 
+The build is made from the branch [tools-releases](https://github.com/kubernetes-sigs/kubebuilder/tree/tools-releases) and the trigger will call the `build/cloudbuild_tools.yaml` passing
 as argument the architecture and the SO that should be used, e.g:
 
 <img width="553" alt="Screenshot 2022-04-30 at 10 15 41" src="https://user-images.githubusercontent.com/7708031/166099666-ae9cd2df-73fe-47f6-a987-464f63df9a19.png">
@@ -91,7 +91,7 @@ These images are can be checked in the consolse, see [here](https://console.clou
 
 The project `kube-rbac-proxy` is in the process to be donated to the k8s org. However, it is going on for a long time and then,
 we have no ETA for that to occur. When that occurs we can automate this process. But until there we need to generate these images
-by bumping the versions/tags released by `kube-rbac-proxy` on the branch 
+by bumping the versions/tags released by `kube-rbac-proxy` on the branch
 [kube-rbac-proxy-releases](https://github.com/kubernetes-sigs/kubebuilder/tree/kube-rbac-proxy-releases)
 then the `build/cloudbuild_kube-rbac-proxy.yaml` will generate the images.
 
@@ -118,8 +118,8 @@ and not the image, see:
         github_token: ${{ secrets.GITHUB_TOKEN }}
 ```
 
-However, the image should still be built and maintained since other projects under the org might be using them. 
+However, the image should still be built and maintained since other projects under the org might be using them.
 
 [kubebuilder-release-tools]: https://github.com/kubernetes-sigs/kubebuilder-release-tools
 [release-notes-generation]: https://github.com/kubernetes-sigs/kubebuilder-release-tools/blob/master/README.md#release-notes-generation
-[release-process]: https://github.com/kubernetes-sigs/kubebuilder/blob/master/VERSIONING.md#releasing 
+[release-process]: https://github.com/kubernetes-sigs/kubebuilder/blob/master/VERSIONING.md#releasing

designs/code-generate-image-plugin.md

@@ -8,26 +8,26 @@
 
 This proposal defines a new plugin which allow users get the scaffold with the
  required code to have a project that will deploy and manage an image on the cluster following the guidelines and what have been considered as good practices.
- 
+
 ## Motivation
 
-The biggest part of the Kubebuilder users looking for to create a project that will at the end only deploy an image. In this way, one of the  mainly motivations of this proposal is to abstract the complexities to achieve this goal and still giving the possibility of users improve and customize their projects according to their requirements. 
+The biggest part of the Kubebuilder users looking for to create a project that will at the end only deploy an image. In this way, one of the  mainly motivations of this proposal is to abstract the complexities to achieve this goal and still giving the possibility of users improve and customize their projects according to their requirements.
 
 **Note:** This plugin will address requests that has been raised for a while and for many users in the community. Check [here](https://github.com/operator-framework/operator-sdk/pull/2158), for example, a request done in the past for the SDK project which is integrated with Kubebuidler to address the same need.
 
 ### Goals
 
 - Add a new plugin to generate the code required to deploy and manage an image on the cluster
 - Promote the best practices as give example of common implementations
-- Make the process to develop  operators projects easier and more agil. 
+- Make the process to develop  operators projects easier and more agil.
 - Give flexibility to the users and allow them to change the code according to their needs
 - Provide examples of code implementations and of the most common features usage and reduce the learning curve
- 
+
 ### Non-Goals
 
-The idea of this proposal is provide a facility for the users. This plugin can be improved 
+The idea of this proposal is provide a facility for the users. This plugin can be improved
 in the future, however, this proposal just covers the basic requirements. In this way, is a non-goal
-allow extra configurations such as; scaffold the project using webhooks and the controller covered by tests. 
+allow extra configurations such as; scaffold the project using webhooks and the controller covered by tests.
 
 ## Proposal
 
@@ -38,12 +38,12 @@ Add the new plugin code generate which will scaffold code implementation to depl
 - Add an EnvVar on the manager manifest (`config/manager/manager.yaml`) which will store the image informed and shows its possibility to users:
 
 ```yaml
-    ..   
+    ..
     spec:
       containers:
         - name: manager
           env:
-            - name: {{ resource}}-IMAGE 
+            - name: {{ resource}}-IMAGE
               value: {{image:tag}}
           image: controller:latest
       ...
@@ -66,9 +66,9 @@ Add the new plugin code generate which will scaffold code implementation to depl
 	}
 ```
 
-- Add the watch feature for the Deployment managed by the controller: 
+- Add the watch feature for the Deployment managed by the controller:
 
-```go 
+```go
 func (r *{{ resource }}Reconciler) SetupWithManager(mgr ctrl.Manager) error {
 	return ctrl.NewControllerManagedBy(mgr).
 		For(&cachev1alpha1.{{ resource }}{}).
@@ -87,19 +87,19 @@ func (r *{{ resource }}Reconciler) SetupWithManager(mgr ctrl.Manager) error {
 
 - Add a [marker][markers] in the spec definition to demonstrate how to use OpenAPI schemas validation such as `+kubebuilder:validation:Minimum=1`
 
-- Add the specs on the `_types.go` to generate the CRD/CR sample with default values for `ImagePullPolicy` (`Always`), `ContainerPort` (`80`) and the `Replicas Size` (`3`) 
+- Add the specs on the `_types.go` to generate the CRD/CR sample with default values for `ImagePullPolicy` (`Always`), `ContainerPort` (`80`) and the `Replicas Size` (`3`)
+
+- Add a finalizer implementation with TODO for the CR managed by the controller such as described in the SDK doc [Handle Cleanup on Deletion](https://sdk.operatorframework.io/docs/building-operators/golang/advanced-topics/#handle-cleanup-on-deletion)
 
-- Add a finalizer implementation with TODO for the CR managed by the controller such as described in the SDK doc [Handle Cleanup on Deletion](https://sdk.operatorframework.io/docs/building-operators/golang/advanced-topics/#handle-cleanup-on-deletion) 
-
 ### User Stories
 
-- I am as user, would like to use a command to scaffold my common need which is deploy an image of my application, so that I do not need to know exactly how to implement it 
+- I am as user, would like to use a command to scaffold my common need which is deploy an image of my application, so that I do not need to know exactly how to implement it
 
-- I am as user, would like to have a good example code base which uses the common features, so that I can easily learn its concepts and have a good start point to address my needs.  
+- I am as user, would like to have a good example code base which uses the common features, so that I can easily learn its concepts and have a good start point to address my needs.
 
 - I am as maintainer, would like to have a good example to address the common questions, so that I can easily describe how to implement the projects and/or use the common features.
- 
-### Implementation Details/Notes/Constraints 
+
+### Implementation Details/Notes/Constraints
 
 **Example of the controller template**
 
@@ -160,9 +160,9 @@ func (r *{{ resource }}.Reconciler) Reconcile(req ctrl.Request) (ctrl.Result, er
 		// Spec updated - return and requeue
 		return ctrl.Result{Requeue: true}, nil
 	}
-	
+
     // TODO: add here code implementation to update/manage the status
-    
+
 	return ctrl.Result{}, nil
 }
 
@@ -214,7 +214,7 @@ func labelsFor{{ resource }}(name string) map[string]string {
 // imageFor{{ resource }} returns the image for the resources
 // belonging to the given {{ resource }} CR name.
 func imageFor{{ resource }}(name string) string {
-	// TODO: this method will return the value of the envvar create to store the image:tag informed 
+	// TODO: this method will return the value of the envvar create to store the image:tag informed
 }
 
 func (r *{{ resource }}Reconciler) SetupWithManager(mgr ctrl.Manager) error {
@@ -224,7 +224,7 @@ func (r *{{ resource }}Reconciler) SetupWithManager(mgr ctrl.Manager) error {
 		Complete(r)
 }
 
-``` 
+```
 
 **Example of the spec for the <kind>_types.go template**
 
@@ -241,7 +241,7 @@ type {{ resource }}Spec struct {
     // ImagePullPolicy defines the policy to pull the container images
 	ImagePullPolicy string `json:"image-pull-policy,omitempty"`
 
-    // ContainerPort specifies the port which will be used by the image container 
+    // ContainerPort specifies the port which will be used by the image container
 	ContainerPort int `json:"container-port,omitempty"`
 
 }
@@ -255,8 +255,8 @@ To ensure this implementation a new project example should be generated in the [
 
 ### Graduation Criteria
 
-- The new plugin will only be support `project-version=3` 
-- The attribute image with the value informed should be added to the resources model in the PROJECT file to let the tool know that the Resource get done with the common basic code implementation: 
+- The new plugin will only be support `project-version=3`
+- The attribute image with the value informed should be added to the resources model in the PROJECT file to let the tool know that the Resource get done with the common basic code implementation:
 
 ```yaml
 plugins:
@@ -267,34 +267,34 @@ plugins:
             kind: Captain
             version: v1
             image: "<some-registry>/<project-name>:<tag>
-``` 
+```
 
-For further information check the definition agreement register in the comment https://github.com/kubernetes-sigs/kubebuilder/issues/1941#issuecomment-778649947. 
+For further information check the definition agreement register in the comment https://github.com/kubernetes-sigs/kubebuilder/issues/1941#issuecomment-778649947.
 
-## Open Questions 
+## Open Questions
 
-1. Should we allow to scaffold the code for an API that is already created for the project? 
-No, at least in the first moment to keep the simplicity.  
+1. Should we allow to scaffold the code for an API that is already created for the project?
+No, at least in the first moment to keep the simplicity.
 
 2. Should we support StatefulSet and Deployments?
 The idea is we start it by using a Deployment. However, we can improve the feature in follow-ups to support more default types of scaffolds which could be like `kubebuilder create api --group=crew --version=v1 --image=myexample:0.0.1 --kind=App --plugins=deploy-image.go.kubebuilder.io/v1beta1 --type=[deployment|statefulset|webhook]`
 
 3. Could this feature be useful to other languages or is it just valid to Go based operators?
 
-This plugin would is reponsable to scaffold content and files for Go-based operators. In a future, if other language-based operators starts to be supported (either officially or by the community) this plugin could be used as reference to create an equivalent one for their languages. Therefore, it should probably not to be a `subdomain` of `go.kubebuilder.io.` 
+This plugin would is reponsable to scaffold content and files for Go-based operators. In a future, if other language-based operators starts to be supported (either officially or by the community) this plugin could be used as reference to create an equivalent one for their languages. Therefore, it should probably not to be a `subdomain` of `go.kubebuilder.io.`
 
 For its integration with SDK, it might be valid for the Ansible-based operators where a new `playbook/role` could be generated as well. However, for example, for the Helm plugin it might to be useless. E.g `deploy-image.ansible.sdk.operatorframework.io/v1beta1`
 
-4. Should we consider create a separate repo for plugins? 
+4. Should we consider create a separate repo for plugins?
 
-In the long term yes. However, see that currently, Kubebuilder has not too many plugins yet. And then, and the preliminary support for plugins did not indeed release. For more info see the [Extensible CLI and Scaffolding Plugins][plugins-phase1-design-doc]. 
+In the long term yes. However, see that currently, Kubebuilder has not too many plugins yet. And then, and the preliminary support for plugins did not indeed release. For more info see the [Extensible CLI and Scaffolding Plugins][plugins-phase1-design-doc].
 
-In this way, at this moment, it shows to be a little Premature Optimization. Note that the issue [#2016](https://github.com/kubernetes-sigs/kubebuilder/issues/1378) will check the possibility of the plugins be as separate binaries that can be discovered by the Kubebuilder CLI binary via user-specified plugin file paths. Then, the discussion over the best approach to dealing with many plugins and if they should or not leave in the Kubebuilder repository would be better addressed after that.  
+In this way, at this moment, it shows to be a little Premature Optimization. Note that the issue [#2016](https://github.com/kubernetes-sigs/kubebuilder/issues/1378) will check the possibility of the plugins be as separate binaries that can be discovered by the Kubebuilder CLI binary via user-specified plugin file paths. Then, the discussion over the best approach to dealing with many plugins and if they should or not leave in the Kubebuilder repository would be better addressed after that.
 
-5. Is Kubebuilder prepared to receive this implementation already? 
+5. Is Kubebuilder prepared to receive this implementation already?
 
 The [Extensible CLI and Scaffolding Plugins - Phase 1.5](extensible-cli-and-scaffolding-plugins-phase-1-5.md) and the issue #1941 requires to be implemented before this proposal. Also, to have a better idea over the proposed solutions made so for the Plugin Ecosystem see the meta issue [#2016](https://github.com/kubernetes-sigs/kubebuilder/issues/2016)
 
-[markers]: ../docs/book/src/reference/markers.md 
+[markers]: ../docs/book/src/reference/markers.md
 [conditions]: https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#typical-status-properties
 [plugins-phase1-design-doc]: https://github.com/kubernetes-sigs/kubebuilder/blob/master/designs/extensible-cli-and-scaffolding-plugins-phase-1.md