docs: keep the proper noun Kubebuilder consistent

Signed-off-by: Daniel Hu <[email protected]>

.github/PULL_REQUEST_TEMPLATE.md

@@ -1,6 +1,6 @@
 <!--
 
-Hiya!  Welcome to KubeBuilder!  For a smooth PR process, please ensure
+Hiya!  Welcome to Kubebuilder!  For a smooth PR process, please ensure
 that you include the following information:
 
 * a description of the change

CONTRIBUTING.md

@@ -125,7 +125,7 @@ You can reach the maintainers of this project at:
 ## Becoming a reviewer or approver
 
 Contributors may eventually become official reviewers or approvers in
-KubeBuilder and the related repositories.  See
+Kubebuilder and the related repositories.  See
 [CONTRIBUTING-ROLES.md](docs/CONTRIBUTING-ROLES.md) for more information.
 
 ## Code of conduct

DESIGN.md

@@ -1,6 +1,6 @@
-# KubeBuilder Design Principles
+# Kubebuilder Design Principles
 
-This lays out some of the guiding design principles behind the KubeBuilder
+This lays out some of the guiding design principles behind the Kubebuilder
 project and its various components.
 
 ## Overarching
@@ -26,15 +26,15 @@ project and its various components.
   coding, and it may involve interoperating with lower-level components,
   but it should be possible without unreasonable friction.
 
-## KubeBuilder
+## Kubebuilder
 
-* **KubeBuilder Has Opinions**: KubeBuilder exists as an opinionated
+* **Kubebuilder Has Opinions**: Kubebuilder exists as an opinionated
   project generator.  It should strive to give users a reasonable project
   layout that's simple enough to understand when getting started, but
   provides room to grow.  It might not match everyone's opinions, but it
   should strive to be useful to most.
 
-* **Batteries Included**: KubeBuilder projects should contain enough
+* **Batteries Included**: Kubebuilder projects should contain enough
   deployment information to reasonably develop and run the scaffolded
   project.  This includes testing, deployment files, and development
   infrastructure to go from code to running containers.

README.md

@@ -12,7 +12,7 @@ Kubebuilder increases velocity and reduces the complexity managed by
 developers for rapidly building and publishing Kubernetes APIs in Go.
 It builds on top of the canonical techniques used to build the core Kubernetes APIs to provide simple abstractions that reduce boilerplate and toil.
 
-**Note:** kubebuilder does not exist as an example to *copy-paste*, but instead provides powerful libraries and tools
+**Note:** Kubebuilder does not exist as an example to *copy-paste*, but instead provides powerful libraries and tools
 to simplify building and publishing Kubernetes APIs from scratch.
 
 Kubebuilder is developed on top of the controller-runtime and controller-tools libraries.
@@ -63,7 +63,7 @@ Building APIs using CRDs, Controllers and Admission Webhooks.
 
 ## Philosophy
 
-See [DESIGN.md](DESIGN.md) for the guiding principles of the various KubeBuilder projects.
+See [DESIGN.md](DESIGN.md) for the guiding principles of the various Kubebuilder projects.
 
 TL;DR:
 

VERSIONING.md

@@ -1,10 +1,10 @@
-# Versioning and Releasing for KubeBuilder
+# Versioning and Releasing for Kubebuilder
 
-We (mostly) follow the [common KubeBuilder versioning
+We (mostly) follow the [common Kubebuilder versioning
 guidelines][guidelines], and use the corresponding tooling and PR process
 described there.
 
-For the purposes of the aforementioned guidelines, KubeBuilder counts as
+For the purposes of the aforementioned guidelines, Kubebuilder counts as
 a "CLI project".
 
 [guidelines]: https://sigs.k8s.io/kubebuilder-release-tools/VERSIONING.md
@@ -42,7 +42,7 @@ cherry-picked to the aforementioned branch to get them to be published.
 The cherry-picks will automatically be published to the book once their PR
 merges.
 
-**When you publish a KubeBuilder release**, be sure to also submit a PR
+**When you publish a Kubebuilder release**, be sure to also submit a PR
 that merges the main branch into [book-v3][book-branch], so that it
 describes the latest changes in the new release.
 
@@ -63,17 +63,17 @@ take care of building and publishing the artifacts.
 
 |   Name	|   Example	|  Description |
 |---	|---	|---	|
-|  KubeBuilder version | `v2.2.0`, `v2.3.0`, `v2.3.1` | Tagged versions of the KubeBuilder project, representing changes to the source code in this repository. See the [releases][kb-releases] page for binary releases. |
+|  Kubebuilder version | `v2.2.0`, `v2.3.0`, `v2.3.1` | Tagged versions of the Kubebuilder project, representing changes to the source code in this repository. See the [releases][kb-releases] page for binary releases. |
 |  Project version |  `"1"`, `"2"`, `"3"` | Project version defines the scheme of a `PROJECT` configuration file. This version is defined in a `PROJECT` file's `version`. |
 |  Plugin version | `v2`, `v3` | Represents the version of an individual plugin, as well as the corresponding scaffolding that it generates. This version is defined in a plugin key, ex. `go.kubebuilder.io/v2`. See the [design doc][cli-plugins-versioning] for more details. |
 
 ### Incrementing versions
 
-For more information on how KubeBuilder release versions work, see the [semver](https://semver.org/) documentation.
+For more information on how Kubebuilder release versions work, see the [semver](https://semver.org/) documentation.
 
-Project versions should only be increased if a breaking change is introduced in the PROJECT file scheme itself. Changes to the Go scaffolding or the KubeBuilder CLI *do not* affect project version.
+Project versions should only be increased if a breaking change is introduced in the PROJECT file scheme itself. Changes to the Go scaffolding or the Kubebuilder CLI *do not* affect project version.
 
-Similarly, the introduction of a new plugin version might only lead to a new minor version release of KubeBuilder, since no breaking change is being made to the CLI itself. It'd only be a breaking change to KubeBuilder if we remove support for an older plugin version. See the plugins design doc [versioning section][cli-plugins-versioning]
+Similarly, the introduction of a new plugin version might only lead to a new minor version release of Kubebuilder, since no breaking change is being made to the CLI itself. It'd only be a breaking change to Kubebuilder if we remove support for an older plugin version. See the plugins design doc [versioning section][cli-plugins-versioning]
 for more details on plugin versioning.
 
 **NOTE:** the scheme for project version `"2"` was defined before the concept of plugins was introduced, so plugin `go.kubebuilder.io/v2` is implicitly used for those project types. Schema for project versions `"3"` and beyond define a `layout` key that informs the plugin system of which plugin to use.
@@ -88,12 +88,12 @@ version numbers and paths. All further breaking changes to the plugin should be
 plugin would then be frozen to breaking changes.
 
 You must also add a migration guide to the [migrations](https://book.kubebuilder.io/migrations.html)
-section of the KubeBuilder book in your PR. It should detail the steps required
+section of the Kubebuilder book in your PR. It should detail the steps required
 for users to upgrade their projects from `vX` to `v(X+1)-alpha`.
 
 ### Example
 
-KubeBuilder scaffolds projects with plugin `go.kubebuilder.io/v3` by default.
+Kubebuilder scaffolds projects with plugin `go.kubebuilder.io/v3` by default.
 
 You create a feature that adds a new marker to the file `main.go` scaffolded by `init`
 that `create api` will use to update that file. The changes introduced in your feature

designs/README.md

@@ -1,12 +1,12 @@
 Designs
 =======
 
-These are design documents for changes to KubeBuilder (and
+These are design documents for changes to Kubebuilder (and
 cross-repository changes for related projects, like controller-runtime and
 controller-tools). They exist to help document the design processes that
-go into writing KubeBuilder, but may not be up-to-date (more below).
+go into writing Kubebuilder, but may not be up-to-date (more below).
 
-Not all changes to KubeBuilder need a design document -- only major ones.
+Not all changes to Kubebuilder need a design document -- only major ones.
 Use your best judgement.
 
 When submitting a design document, we encourage having written
@@ -17,10 +17,10 @@ proof-of-concept process can help iron out wrinkles and can help with the
 
 ## Out-of-Date Designs
 
-**KubeBuilder documentation (the [book](https://book.kubebuilder.io) and
+**Kubebuilder documentation (the [book](https://book.kubebuilder.io) and
 the [GoDoc](https://pkg.go.dev/sigs.k8s.io/controller-runtime?tab=doc)) should be
 considered the canonical, update-to-date reference and architectural
-documentation** for KubeBuilder.
+documentation** for Kubebuilder.
 
 However, if you see an out-of-date design document, feel free to submit
 a PR marking it as such, and add an addendum linking to issues documenting

designs/simplified-scaffolding.md

@@ -97,27 +97,27 @@ $ tree ./test/project/pkg/controller
 
 ## Motivation
 
-The current scaffolding in KubeBuilder has two main problems:
+The current scaffolding in Kubebuilder has two main problems:
 comprehensibility and dependency passing.
 
 ### Complicated Initial Structure
 
-While the structure of KubeBuilder projects will likely feel at home for
+While the structure of Kubebuilder projects will likely feel at home for
 existing Kubernetes contributors (since it matches the structure of
 Kubernetes itself quite closely), it provides a fairly convoluted
 experience out of the box.
 
 Even for a single controller and API type (without a webhook), it
 generates 8 API-related files and 5 controller-related files.  Of those
-files, 6 are KubeBuilder-specific glue code, 4 are test setup, and
+files, 6 are Kubebuilder-specific glue code, 4 are test setup, and
 1 contains standard Kubernetes glue code, leaving only 2 with actual
 user-edited code.
 
 This proliferation of files makes it difficult for users to understand how
 their code relates to the library, posing some barrier for initial adoption
 and moving beyond a basic knowledge of functionality to actual
 understanding of the structure.  A common line of questioning amongst
-newcomers to KubeBuilder includes "where should I put my code that adds
+newcomers to Kubebuilder includes "where should I put my code that adds
 new types to a scheme" (and similar questions), which indicates that it's
 not immediately obvious to these users why the project is structured the
 way it is.
@@ -148,13 +148,13 @@ construction of controllers (e.g. this [one file
 controller](https://github.com/DirectXMan12/sample-controller/blob/workshop/main.go)
 used as a getting started example for a workshop).
 
-Current KubeBuilder scaffolding does not take advantage of the builder,
+Current Kubebuilder scaffolding does not take advantage of the builder,
 leaving generated code using the lower-level constructs which require more
 understanding of the internals of controller-runtime to comprehend.
 
 ### Dependency Passing Woes
 
-Another common line of questioning amongst KubeBuilder users is "how to
+Another common line of questioning amongst Kubebuilder users is "how to
 I pass dependencies to my controllers?".  This ranges from "how to I pass
 custom clients for the software I'm running" to "how to I pass
 configuration from files and flags down to my controllers" (e.g.
@@ -300,7 +300,7 @@ There are three options here:
    bury types deeper in a directory structure.
 
 2. Try to move things and rename references.  This takes a lot more effort
-   on the KubeBuilder maintainers' part if we try to rename references
+   on the Kubebuilder maintainers' part if we try to rename references
    across the codebase.  Not so much if we force the user to, but that's
    a poorer experience.
 
@@ -332,9 +332,9 @@ registering types to the scheme, and we can always fall back to emitting
 code for the user to place in manually if we can't find the correct
 comment.
 
-### Making this work with Existing KubeBuilder Installations
+### Making this work with Existing Kubebuilder Installations
 
-KubeBuilder projects currently have a `PROJECT` file that can be used to
+Kubebuilder projects currently have a `PROJECT` file that can be used to
 store information about project settings.  We can make use of this to
 store a "scaffolding version", where we increment versions when making
 incompatible changes to how the scaffolding works.

docs/CONTRIBUTING-ROLES.md

@@ -4,7 +4,7 @@ Contributing Roles
 ## Direct Code-Related Roles
 
 While anyone (who's signed the [CLA and follows the code of
-conduct](../CONTRIBUTING.md)) is welcome to contribute to the KubeBuilder
+conduct](../CONTRIBUTING.md)) is welcome to contribute to the Kubebuilder
 project, we've got two "formal" roles that carry additional privileges and
 responsibilities: *reviewer* and *approver*.
 
@@ -25,10 +25,10 @@ kubebuilder-admins in the `OWNERS_ALIASES` file).
 Anyone who wants to become a reviewer or approver must first be a [member
 of the Kubernetes project][kube-member].  The aforementioned doc has more
 details, but the gist is that you must have made a couple contributions to
-some part of the Kubernetes project -- *this includes KubeBuilder and
+some part of the Kubernetes project -- *this includes Kubebuilder and
 related repos*.  Then, you need two existing members to sponsor you.
 
-**If you've contributed a few times to KubeBuilder, we'll be happy to
+**If you've contributed a few times to Kubebuilder, we'll be happy to
 sponsor you, just ping us on Slack :-)**
 
 ## Reviewers

docs/book/src/cronjob-tutorial/cronjob-tutorial.md

@@ -9,7 +9,7 @@ building up to something pretty full-featured.
 Let's pretend (and sure, this is a teensy bit contrived) that we've
 finally gotten tired of the maintenance burden of the non-Kubebuilder
 implementation of the CronJob controller in Kubernetes, and we'd like to
-rewrite it using KubeBuilder.
+rewrite it using Kubebuilder.
 
 The job (no pun intended) of the *CronJob* controller is to run one-off
 tasks on the Kubernetes cluster at regular intervals.  It does this by

docs/book/src/cronjob-tutorial/epilogue.md

@@ -2,7 +2,7 @@
 
 By this point, we've got a pretty full-featured implementation of the
 CronJob controller, made use of most of the features of
-KubeBuilder, and written tests for the controller using envtest.
+Kubebuilder, and written tests for the controller using envtest.
 
 If you want more, head over to the [Multi-Version
 Tutorial](/multiversion-tutorial/tutorial.md) to learn how to add new API

docs/book/src/logos/README.md

@@ -1,4 +1,4 @@
-# KubeBuilder Logos
+# Kubebuilder Logos
 
 The official location for the logos is in a [public GCS
 bucket][kb-logos-gcs] (or if you like GCS XML listings,

docs/book/src/migration/legacy/migration_guide_v1tov2.md

@@ -96,7 +96,7 @@ We can replace the `+k8s:deepcopy-gen:interfaces=...` marker (which is
 `+kubebuilder:object:root=true`.
 
 We don't need the following markers any more (they're not used anymore, and are
-relics from much older versions of KubeBuilder):
+relics from much older versions of Kubebuilder):
 
 ```go
 // +genclient

docs/book/src/migration/multi-group.md

@@ -5,7 +5,7 @@
 <h1>Note</h1>
 
 Multi-group scaffolding support was not present in the initial version of
-the KubeBuilder v2 scaffolding (as of KubeBuilder v2.0.0).
+the Kubebuilder v2 scaffolding (as of Kubebuilder v2.0.0).
 
 To change the layout of your project to support Multi-Group run the command
 `kubebuilder edit --multigroup=true`. Once you switch to a multi-group layout, the new Kinds
@@ -14,7 +14,7 @@ to move the old API groups to the new layout.
 
 </aside>
 
-While KubeBuilder v2 will not scaffold out a project structure compatible
+While Kubebuilder v2 will not scaffold out a project structure compatible
 with multiple API groups in the same repository by default, it's possible
 to modify the default project structure to support it.
 
@@ -68,7 +68,7 @@ repo: tutorial.kubebuilder.io/project
 multigroup: true
 ```
 
-Note that this option indicates to KubeBuilder that this is a multi-group project. 
+Note that this option indicates to Kubebuilder that this is a multi-group project. 
 
 In this way, if the project is not new and has previous APIs already implemented will be in the previous structure. 
 Notice that with the `multi-group` project the Kind API's files are
@@ -87,8 +87,8 @@ For envtest to install CRDs correctly into the test environment, the relative pa
 ```
 
 The [CronJob tutorial][cronjob-tutorial] explains each of these changes in
-more detail (in the context of how they're generated by KubeBuilder for
+more detail (in the context of how they're generated by Kubebuilder for
 single-group projects).
 
-[multi-group-issue]: https://github.com/kubernetes-sigs/kubebuilder/issues/923 "KubeBuilder Issue #923"
+[multi-group-issue]: https://github.com/kubernetes-sigs/kubebuilder/issues/923 "Kubebuilder Issue #923"
 [cronjob-tutorial]: /cronjob-tutorial/cronjob-tutorial.md "Tutorial: Building CronJob"

docs/book/src/migrations.md

@@ -1,8 +1,8 @@
 # Migrations
 
-Migrating between project structures in KubeBuilder generally involves
+Migrating between project structures in Kubebuilder generally involves
 a bit of manual work.
 
 This section details what's required to migrate, between different
-versions of KubeBuilder scaffolding, as well as to more complex project
+versions of Kubebuilder scaffolding, as well as to more complex project
 layout structures.

docs/book/src/multiversion-tutorial/conversion-concepts.md

@@ -52,7 +52,7 @@ the version stored by the API server.
 In that case, the API server needs to know how to convert between the
 desired version and the stored version.  Since the conversions aren't
 built in for CRDs, the Kubernetes API server calls out to a webhook to do
-the conversion instead.  For KubeBuilder, this webhook is implemented by
+the conversion instead.  For Kubebuilder, this webhook is implemented by
 controller-runtime, and performs the hub-and-spoke conversions that we
 discussed above.
 

docs/book/src/plugins/plugins.md

@@ -1,6 +1,6 @@
 # Plugins
 
-Since the `3.0.0` KubeBuilder version, preliminary support for plugins was added. You can [Extend the CLI and Scaffolds][extending-cli] as well. See that when users run the CLI commands to perform the scaffolds, the plugins are used:
+Since the `3.0.0` Kubebuilder version, preliminary support for plugins was added. You can [Extend the CLI and Scaffolds][extending-cli] as well. See that when users run the CLI commands to perform the scaffolds, the plugins are used:
 
 - To initialize a project with a chain of global plugins:
 

docs/book/src/reference/controller-gen.md

@@ -1,6 +1,6 @@
 # controller-gen CLI
 
-KubeBuilder makes use of a tool called
+Kubebuilder makes use of a tool called
 [controller-gen](https://sigs.k8s.io/controller-tools/cmd/controller-gen)
 for generating utility code and Kubernetes YAML.  This code and config
 generation is controlled by the presence of special ["marker

docs/book/src/reference/generating-crd.md

@@ -1,6 +1,6 @@
 # Generating CRDs
 
-KubeBuilder uses a tool called [`controller-gen`][controller-tools] to
+Kubebuilder uses a tool called [`controller-gen`][controller-tools] to
 generate utility code and Kubernetes object YAML, like
 CustomResourceDefinitions.
 
@@ -10,7 +10,7 @@ packages.  In the case of CRDs, these are generally pulled from your
 `_types.go` files.  For more information on markers, see the [marker
 reference docs][marker-ref].
 
-KubeBuilder provides a `make` target to run controller-gen and generate
+Kubebuilder provides a `make` target to run controller-gen and generate
 CRDs: `make manifests`.
 
 When you run `make manifests`, you should see CRDs generated under the
@@ -157,7 +157,7 @@ in your CRD, and use a webhook to convert between them.
 For more details on this process, see the [multiversion
 tutorial](/multiversion-tutorial/tutorial.md).
 
-By default, KubeBuilder disables generating different validation for
+By default, Kubebuilder disables generating different validation for
 different versions of the Kind in your CRD, to be compatible with older
 Kubernetes versions.
 
@@ -194,7 +194,7 @@ to `CRD_OPTIONS ?= crd:trivialVersions=true`
 
 ## Under the hood
 
-KubeBuilder scaffolds out make rules to run `controller-gen`.  The rules
+Kubebuilder scaffolds out make rules to run `controller-gen`.  The rules
 will automatically install controller-gen if it's not on your path using
 `go get` with Go modules.