-
Notifications
You must be signed in to change notification settings - Fork 1.4k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
🌱 fix triling spaces in the docs and add check as automate fix to the…
… make generate
- Loading branch information
1 parent
1bd70b3
commit 3df5ed5
Showing
137 changed files
with
8,736 additions
and
8,683 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,30 +1,30 @@ | ||
<!-- | ||
Hiya! Welcome to Kubebuilder! For a smooth PR process, please ensure | ||
that you include the following information: | ||
Hiya!WelcometoKubebuilder!ForasmoothPRprocess,pleaseensure | ||
thatyouincludethefollowinginformation: | ||
* a description of the change | ||
* the motivation for the change | ||
* what issue it fixes, if any, in GitHub syntax (e.g. Fixes #XYZ) | ||
*adescriptionofthechange | ||
*themotivationforthechange | ||
*whatissueitfixes,ifany,inGitHubsyntax(e.g.Fixes#XYZ) | ||
Both the description and motivation may reference other issues and PRs, | ||
but should be mostly understandable without following the links (e.g. when | ||
reading the git commit log). | ||
BoththedescriptionandmotivationmayreferenceotherissuesandPRs, | ||
butshouldbemostlyunderstandablewithoutfollowingthelinks(e.g.when | ||
readingthegitcommitlog). | ||
Please don't @-mention people in PR or commit messages (do so in an | ||
additional comment). | ||
Pleasedon't@-mentionpeopleinPRorcommitmessages(dosoinan | ||
additionalcomment). | ||
please add an icon to the title of this PR depending on the type: | ||
pleaseaddanicontothetitleofthisPRdependingonthetype: | ||
- ⚠ (:warning:): breaking | ||
- ✨ (:sparkles:): new non-breaking feature | ||
- 🐛 (:bug:): bugfix | ||
- 📖 (:book:): documentation | ||
- 🌱 (:seedling:): infrastructure/other | ||
-⚠(:warning:):breaking | ||
-✨(:sparkles:):newnon-breakingfeature | ||
-🐛(:bug:):bugfix | ||
-📖(:book:):documentation | ||
-🌱(:seedling:):infrastructure/other | ||
See https://sigs.k8s.io/kubebuilder-release-tools for more information. | ||
Seehttps://sigs.k8s.io/kubebuilder-release-toolsformoreinformation. | ||
**PLEASE REMOVE THIS COMMENT BLOCK BEFORE SUBMITTING THE PR** (the bits | ||
between the arrows) | ||
**PLEASEREMOVETHISCOMMENTBLOCKBEFORESUBMITTINGTHEPR**(thebits | ||
betweenthearrows) | ||
--> |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -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 |
Large diffs are not rendered by default.
Oops, something went wrong.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,117 +1,117 @@ | ||
# Kubebuilder Design Principles | ||
|
||
This lays out some of the guiding design principles behind the Kubebuilder | ||
project and its various components. | ||
|
||
## Overarching | ||
|
||
* **Libraries Over Code Generation**: Generated code is messy to maintain, | ||
hard for humans to change and understand, and hard to update. Library | ||
code is easy to update (just increase your dependency version), easier | ||
to version using existing mechanisms, and more concise. | ||
|
||
* **Copy-pasting is bad**: Copy-pasted code suffers from similar problems | ||
as code generation, except more acutely. Copy-pasted code is nearly | ||
impossible to easy update, and frequently suffers from bugs and | ||
misunderstandings. If something is being copy-pasted, it should | ||
refactored into a library component or remote | ||
[kustomize](https://sigs.k8s.io/kustomize) base. | ||
|
||
* **Common Cases Should Be Easy**: The 80-90% common cases should be | ||
simple and easy for users to understand. | ||
|
||
* **Uncommon Cases Should Be Possible**: There shouldn't be situations | ||
where it's downright impossible to do something within | ||
controller-runtime or controller-tools. It may take extra digging or | ||
coding, and it may involve interoperating with lower-level components, | ||
but it should be possible without unreasonable friction. | ||
|
||
## Kubebuilder | ||
|
||
* **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 | ||
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. | ||
|
||
## controller-tools and controller-runtime | ||
|
||
* **Sufficient But Composable**: controller-tools and controller-runtime | ||
should be sufficient for building a custom controller by hand. While | ||
scaffolding and additional libraries may make life easier, building | ||
without should be as painless as possible. That being said, they should | ||
strive to be usable as building blocks for higher-level libraries as | ||
well. | ||
|
||
* **Self-Sufficient Docs**: controller-tools and controller-runtime should | ||
strive to have self-sufficient docs (i.e. documentation that doesn't | ||
require reading other libraries' documentation for common use cases). | ||
Examples should be plentiful. | ||
|
||
* **Contained Arcana**: Developers should not need to be experts in | ||
Kubernetes API machinery to develop controllers, but those familiar with | ||
Kubernetes API machinery should not feel out of place. Abstractions | ||
should be intuitive to new users but feel familiar to experienced ones. | ||
Abstractions should embrace the concepts of Kubernetes (e.g. declarative | ||
idempotent reconcilers) while simplifying the details. | ||
|
||
## controller-runtime | ||
|
||
* **Abstractions Should Be Layered**: Abstractions should be built on top | ||
of lower layers, such that advanced users can write custom logic while | ||
still working within the existing model. For instance, the controller | ||
builder is built on top of the event, source, and handler helpers, which | ||
are in turn built for use with the event, source, and handler | ||
interfaces. | ||
|
||
* **Repetitive Stress Injuries Are Bad**: | ||
When possible, commonly used pieces should be exposed in a way that | ||
enables clear, concise code. This includes aliasing groups of | ||
functionality under "alias" or "prelude" packages to avoid having 40 | ||
lines of imports, including common idioms as flexible helpers, and | ||
infering resource information from the user's object types in client | ||
code. | ||
|
||
* **A Little Bit of Magic Goes a Long Way**: In absence of generics, | ||
reflection is acceptable, especially when it leads to clearer, conciser | ||
code. However, when possible interfaces that use reflection should be | ||
designed to avoid requiring the end-developer to use type assertions, | ||
string splitting, which are error-prone and repetitive. These should be | ||
dealt with inside controller-runtime internals. | ||
|
||
* **Defaults Over Constructors**: When not a huge performance impact, | ||
favor auto-defaulting and `Options` structs over constructors. | ||
Constructors quickly become unclear due to lack of names associated | ||
with values, and don't work well with optional values. | ||
|
||
## Development | ||
|
||
* **Words Are Better Than Letters**: Don't abbreviate variable names | ||
unless it's blindingly obvious what they are (e.g. `ctx` for `Context`). | ||
Single- and double-letter method receivers are acceptable, but single- | ||
and double-letter variables quickly become confusing the longer a code | ||
block gets. | ||
|
||
* **Well-commented code**: Code should be commented and given Godocs, even | ||
private methods and functions. It may *seem* obvious what they do at the | ||
time and why, but you might forget, and others will certainly come along. | ||
|
||
* **Test Behaviors**: Test cases should be comprehensible as sets of | ||
expected behaviors. Test cases read without code (e.g. just using `It`, | ||
`Describe`, `Context`, and `By` lines) should still be able to explain | ||
what's required of the tested interface. Testing behaviors makes | ||
internal refactors easier, and makes reading tests easier. | ||
|
||
* **Real Components Over Mocks**: Avoid mocks and recording actions. Mocks | ||
tend to be brittle and gradually become more complicated over time (e.g. | ||
fake client implementations tend to grow into poorly-written, incomplete | ||
API servers). Recording of actions tends to lead to brittle tests that | ||
requires changes during refactors. Instead, test that the end desired | ||
state is correct. Test the way the world should be, without caring how | ||
it got there, and provide easy ways to set up the real components so | ||
that mocks aren't required. | ||
#KubebuilderDesignPrinciples | ||
|
||
ThislaysoutsomeoftheguidingdesignprinciplesbehindtheKubebuilder | ||
projectanditsvariouscomponents. | ||
|
||
##Overarching | ||
|
||
***LibrariesOverCodeGeneration**:Generatedcodeismessytomaintain, | ||
hardforhumanstochangeandunderstand,andhardtoupdate.Library | ||
codeiseasytoupdate(justincreaseyourdependencyversion),easier | ||
toversionusingexistingmechanisms,andmoreconcise. | ||
|
||
***Copy-pastingisbad**:Copy-pastedcodesuffersfromsimilarproblems | ||
ascodegeneration,exceptmoreacutely.Copy-pastedcodeisnearly | ||
impossibletoeasyupdate,andfrequentlysuffersfrombugsand | ||
misunderstandings.Ifsomethingisbeingcopy-pasted,itshould | ||
refactoredintoalibrarycomponentorremote | ||
[kustomize](https://sigs.k8s.io/kustomize)base. | ||
|
||
***CommonCasesShouldBeEasy**:The80-90%commoncasesshouldbe | ||
simpleandeasyforuserstounderstand. | ||
|
||
***UncommonCasesShouldBePossible**:Thereshouldn'tbesituations | ||
whereit'sdownrightimpossibletodosomethingwithin | ||
controller-runtimeorcontroller-tools.Itmaytakeextradiggingor | ||
coding,anditmayinvolveinteroperatingwithlower-levelcomponents, | ||
butitshouldbepossiblewithoutunreasonablefriction. | ||
|
||
##Kubebuilder | ||
|
||
***KubebuilderHasOpinions**:Kubebuilderexistsasanopinionated | ||
projectgenerator.Itshouldstrivetogiveusersareasonableproject | ||
layoutthat'ssimpleenoughtounderstandwhengettingstarted,but | ||
providesroomtogrow.Itmightnotmatcheveryone'sopinions,butit | ||
shouldstrivetobeusefultomost. | ||
|
||
***BatteriesIncluded**:Kubebuilderprojectsshouldcontainenough | ||
deploymentinformationtoreasonablydevelopandrunthescaffolded | ||
project.Thisincludestesting,deploymentfiles,anddevelopment | ||
infrastructuretogofromcodetorunningcontainers. | ||
|
||
##controller-toolsandcontroller-runtime | ||
|
||
***SufficientButComposable**:controller-toolsandcontroller-runtime | ||
shouldbesufficientforbuildingacustomcontrollerbyhand.While | ||
scaffoldingandadditionallibrariesmaymakelifeeasier,building | ||
withoutshouldbeaspainlessaspossible.Thatbeingsaid,theyshould | ||
strivetobeusableasbuildingblocksforhigher-levellibrariesas | ||
well. | ||
|
||
***Self-SufficientDocs**:controller-toolsandcontroller-runtimeshould | ||
strivetohaveself-sufficientdocs(i.e.documentationthatdoesn't | ||
requirereadingotherlibraries'documentationforcommonusecases). | ||
Examplesshouldbeplentiful. | ||
|
||
***ContainedArcana**:Developersshouldnotneedtobeexpertsin | ||
KubernetesAPImachinerytodevelopcontrollers,butthosefamiliarwith | ||
KubernetesAPImachineryshouldnotfeeloutofplace.Abstractions | ||
shouldbeintuitivetonewusersbutfeelfamiliartoexperiencedones. | ||
AbstractionsshouldembracetheconceptsofKubernetes(e.g.declarative | ||
idempotentreconcilers)whilesimplifyingthedetails. | ||
|
||
##controller-runtime | ||
|
||
***AbstractionsShouldBeLayered**:Abstractionsshouldbebuiltontop | ||
oflowerlayers,suchthatadvanceduserscanwritecustomlogicwhile | ||
stillworkingwithintheexistingmodel.Forinstance,thecontroller | ||
builderisbuiltontopoftheevent,source,andhandlerhelpers,which | ||
areinturnbuiltforusewiththeevent,source,andhandler | ||
interfaces. | ||
|
||
***RepetitiveStressInjuriesAreBad**: | ||
Whenpossible,commonlyusedpiecesshouldbeexposedinawaythat | ||
enablesclear,concisecode.Thisincludesaliasinggroupsof | ||
functionalityunder"alias"or"prelude"packagestoavoidhaving40 | ||
linesofimports,includingcommonidiomsasflexiblehelpers,and | ||
inferingresourceinformationfromtheuser'sobjecttypesinclient | ||
code. | ||
|
||
***ALittleBitofMagicGoesaLongWay**:Inabsenceofgenerics, | ||
reflectionisacceptable,especiallywhenitleadstoclearer,conciser | ||
code.However,whenpossibleinterfacesthatusereflectionshouldbe | ||
designedtoavoidrequiringtheend-developertousetypeassertions, | ||
stringsplitting,whichareerror-proneandrepetitive.Theseshouldbe | ||
dealtwithinsidecontroller-runtimeinternals. | ||
|
||
***DefaultsOverConstructors**:Whennotahugeperformanceimpact, | ||
favorauto-defaultingand`Options`structsoverconstructors. | ||
Constructorsquicklybecomeunclearduetolackofnamesassociated | ||
withvalues,anddon'tworkwellwithoptionalvalues. | ||
|
||
##Development | ||
|
||
***WordsAreBetterThanLetters**:Don'tabbreviatevariablenames | ||
unlessit'sblindinglyobviouswhattheyare(e.g.`ctx`for`Context`). | ||
Single-anddouble-lettermethodreceiversareacceptable,butsingle- | ||
anddouble-lettervariablesquicklybecomeconfusingthelongeracode | ||
blockgets. | ||
|
||
***Well-commentedcode**:CodeshouldbecommentedandgivenGodocs,even | ||
privatemethodsandfunctions.Itmay*seem*obviouswhattheydoatthe | ||
timeandwhy,butyoumightforget,andotherswillcertainlycomealong. | ||
|
||
***TestBehaviors**:Testcasesshouldbecomprehensibleassetsof | ||
expectedbehaviors.Testcasesreadwithoutcode(e.g.justusing`It`, | ||
`Describe`,`Context`,and`By`lines)shouldstillbeabletoexplain | ||
what'srequiredofthetestedinterface.Testingbehaviorsmakes | ||
internalrefactorseasier,andmakesreadingtestseasier. | ||
|
||
***RealComponentsOverMocks**:Avoidmocksandrecordingactions.Mocks | ||
tendtobebrittleandgraduallybecomemorecomplicatedovertime(e.g. | ||
fakeclientimplementationstendtogrowintopoorly-written,incomplete | ||
APIservers).Recordingofactionstendstoleadtobrittleteststhat | ||
requireschangesduringrefactors.Instead,testthattheenddesired | ||
stateiscorrect.Testthewaytheworldshouldbe,withoutcaringhow | ||
itgotthere,andprovideeasywaystosetuptherealcomponentsso | ||
thatmocksaren'trequired. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.