fix: improve CLI flag descriptions and help text for create api command#5628
fix: improve CLI flag descriptions and help text for create api command#5628yosofbadr wants to merge 1 commit intokubernetes-sigs:masterfrom
Conversation
|
|
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: yosofbadr The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
Welcome @yosofbadr! |
|
Hi @yosofbadr. Thanks for your PR. I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with Regular contributors should join the org to skip this step. Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
|
|
||
| # Generate the manifests | ||
| make manifests | ||
| # Add a second controller for an existing resource |
There was a problem hiding this comment.
| # Add a second controller for an existing resource | |
| # Add a controller for an existing resource |
It might be the second or not
Example, I scaffold the API only ( controller=false ) then I scaffold the controller only
|
Very nice work 🎉 |
Address review feedback on the create api help text: - Replace "Scaffold" with "Create" in command descriptions and the long-form help, matching the subcommand name and the preferred wording. - Standardize boolean flag descriptions with the "If set, ... Default: ..." pattern for --make, --force, --resource, --namespaced, and --controller. - Add examples for the common "create a controller for an existing resource" and "controller for an external API" flows, which were previously undocumented. Signed-off-by: Yosof Badr <23705518+YosofBadr@users.noreply.github.com>
cece673 to
e7955f1
Compare
|
Thanks @camilamacedo86 for the detailed review — I've pushed e7955f1 addressing the feedback:
Note: the upstream changes to The build and |
There was a problem hiding this comment.
Pull request overview
Improves the kubebuilder create api help UX by updating command descriptions, examples, and several flag help strings to be more discoverable and consistent across the CLI.
Changes:
- Updates
create apilong description and examples, including external API/controller workflows. - Rewrites several
create apiflag descriptions (--make,--resource,--namespaced,--controller) for clarity. - Adjusts
create/create apiCLI Short/Long help text terminology (“Scaffold” → “Create”).
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 9 comments.
Show a summary per file
| File | Description |
|---|---|
| pkg/plugins/golang/v4/api.go | Updates create api metadata (description/examples) and several flag help strings. |
| pkg/cli/create.go | Updates create command Short/Long help text wording. |
| pkg/cli/api.go | Updates create api command Short/Long help text wording. |
| pkg/cli/resource.go | Updates shared --group/--version/--kind flag descriptions for better examples/discoverability. |
| pkg/cli/root.go | Updates shared --plugins / --project-version flag descriptions. |
| pkg/cli/init.go | Updates --project-version flag description for init command registration. |
Comments suppressed due to low confidence (1)
pkg/plugins/golang/v4/api.go:100
- PR description says the help examples were updated to replace raw editor/
makesteps, but the examples still includenano ...and severalmake ...commands below. Either update the PR description or revise these examples to match the stated goal.
# Edit the API Scheme
nano api/v1beta1/frigate_types.go
# Edit the Controller
nano internal/controller/frigate/frigate_controller.go
# Edit the Controller Test
nano internal/controller/frigate/frigate_controller_test.go
# Generate the manifests
make manifests
# Install CRDs into the Kubernetes cluster using kubectl apply
make install
# Regenerate code and run against the Kubernetes cluster configured by ~/.kube/config
make run
| After the files are created, the dependencies will be updated and | ||
| make generate will be run. |
There was a problem hiding this comment.
The long description says "make generate will be run", but PostScaffold only runs make generate when --make is true and the resource has an API (p.resource.HasAPI()). Please adjust the wording to reflect the conditional behavior (and/or mention the --make=false opt-out).
| After the files are created, the dependencies will be updated and | |
| make generate will be run. | |
| After the files are created, the dependencies will be updated. | |
| If --make is not set to false and the resource has an API, | |
| make generate will also be run. |
| After the files are created, the dependencies will be updated and | ||
| make generate will be run. | ||
| ` | ||
| subcmdMeta.Examples = fmt.Sprintf(` # Create a frigates API with Group: ship, Version: v1beta1 and Kind: Frigate |
There was a problem hiding this comment.
Typo in example text: "a frigates API" should be singular ("a frigate API").
| subcmdMeta.Examples = fmt.Sprintf(` # Create a frigates API with Group: ship, Version: v1beta1 and Kind: Frigate | |
| subcmdMeta.Examples = fmt.Sprintf(` # Create a frigate API with Group: ship, Version: v1beta1 and Kind: Frigate |
| fs.BoolVar(&p.runMake, "make", true, | ||
| "Run 'make generate' after generating files (enabled by default; use --make=false to disable)") | ||
| "If set, run 'make generate' after creating files. Default: true. "+ | ||
| "Use --make=false to skip running make generate") |
There was a problem hiding this comment.
--make help text is written as "If set... Default: true" but this flag is default-true (opt-out) and the repo's CLI description standards recommend phrasing like "Run ... (enabled by default; use --make=false to disable)". Also note that make generate only runs when p.resource.HasAPI(); the current wording implies it always runs after creating files.
| "If set, create the resource without prompting. Default: true. "+ | ||
| "Use --resource=false to skip resource creation (e.g., when adding a controller for an existing or external API)") |
There was a problem hiding this comment.
--resource help text says it will create the resource "without prompting" and that the default is true, but the implementation prompts when the flag isn't explicitly set (if !p.resourceFlag.Changed { ... util.YesNo(...) }). The wording should reflect the prompting behavior (see .agents/skills/cli-descriptions/SKILL.md:83-94 for the recommended pattern).
| "If set, create the resource without prompting. Default: true. "+ | |
| "Use --resource=false to skip resource creation (e.g., when adding a controller for an existing or external API)") | |
| "If set, create the resource. "+ | |
| "Use --resource=false to skip resource creation (e.g., when adding a controller for an existing or external API). "+ | |
| "If not specified, you may be prompted to confirm whether to create the resource") |
| "If set, create a namespaced resource. Default: true. "+ | ||
| "Use --namespaced=false to create a cluster-scoped resource") |
There was a problem hiding this comment.
--namespaced help text uses the "If set... Default: true" pattern, but this is a default-true (opt-out) flag. The repo's CLI description standards recommend phrasing like "Resource is namespaced by default; use --namespaced=false to create a cluster-scoped resource" (.agents/skills/cli-descriptions/SKILL.md:48-68).
| "If set, create a namespaced resource. Default: true. "+ | |
| "Use --namespaced=false to create a cluster-scoped resource") | |
| "Resource is namespaced by default; use --namespaced=false to create a cluster-scoped resource") |
| Short: "Create a Kubernetes API or webhook", | ||
| Long: fmt.Sprintf(`Create a Kubernetes API or webhook. |
There was a problem hiding this comment.
This changes the create command help from "Scaffold" to "Create", but related subcommands (e.g., create webhook) still use "Scaffold" in their Short/Long help (see pkg/cli/webhook.go:33-35). Consider using consistent terminology across create and its subcommands to avoid confusing users.
| Short: "Create a Kubernetes API or webhook", | |
| Long: fmt.Sprintf(`Create a Kubernetes API or webhook. | |
| Short: "Scaffold a Kubernetes API or webhook", | |
| Long: fmt.Sprintf(`Scaffold a Kubernetes API or webhook. |
There was a problem hiding this comment.
I think Scaffold was a good suggestion.
I think we changed that see that acrros the project, we have a skill as well now: https://github.com/kubernetes-sigs/kubebuilder/tree/master/.agents/skills/cli-descriptions
| Short: "Create a Kubernetes API", | ||
| Long: `Create a Kubernetes API by writing a Resource definition and/or a Controller.`, |
There was a problem hiding this comment.
create api Short/Long help now uses "Create", while create webhook still uses "Scaffold" (pkg/cli/webhook.go:33-35). Consider aligning the terminology across create subcommands for a consistent help UX.
| Short: "Create a Kubernetes API", | |
| Long: `Create a Kubernetes API by writing a Resource definition and/or a Controller.`, | |
| Short: "Scaffold a Kubernetes API", | |
| Long: `Scaffold a Kubernetes API by writing a Resource definition and/or a Controller.`, |
| # Edit the API Scheme | ||
| # Add a controller for an existing resource (e.g., an additional reconciler) | ||
| %[1]s create api --group ship --version v1beta1 --kind Frigate \ | ||
| --resource=false --controller-name frigate-status |
There was a problem hiding this comment.
The "add a controller" example omits --controller=true, so it will prompt interactively by default (since the code prompts when the flag isn't explicitly set). Consider making the example non-interactive by including an explicit --controller=true (and similarly any other prompting flags).
| --resource=false --controller-name frigate-status | |
| --resource=false --controller=true --controller-name frigate-status |
| "If set, create the controller. Default: true. "+ | ||
| "Use --controller=false to skip controller creation") |
There was a problem hiding this comment.
--controller help text says "Default: true" and suggests --controller=false to skip creation, but the command prompts when the flag isn't explicitly set (if !p.controllerFlag.Changed { ... }). Please use the prompting-flag wording (e.g., "Prompt whether to generate the controller by default; use --controller=true or --controller=false to skip the prompt") per .agents/skills/cli-descriptions/SKILL.md:83-94.
| "If set, create the controller. Default: true. "+ | |
| "Use --controller=false to skip controller creation") | |
| "Prompt whether to generate the controller by default; "+ | |
| "use --controller=true or --controller=false to skip the prompt") |
Summary
Addresses #5446 by improving the CLI help UX for the
create apicommand and shared flags.create apilong description with organized flag categories (required, resource, controller, external API) so users can quickly find what they neednanoandmakesteps) with actionable kubebuilder examples covering common workflows: resource-only, controller-only, cluster-scoped, multiple controllers, and external API scaffolding--group,--version,--kind,--plugins,--project-version) for discoverabilityFollowing the maintainer's suggestion in #5498 to submit small, focused PRs per command.
Files changed
pkg/plugins/golang/v4/api.go-- main improvements tocreate apidescription, examples, and flag textpkg/cli/resource.go-- improved--group,--version,--kindflag descriptions (shared bycreate apiandcreate webhook)pkg/cli/root.go-- improved--pluginsand--project-versionflag descriptionspkg/cli/init.go-- improved--project-versionflag description (init-specific registration)Test plan
go build ./...passesgo test ./pkg/cli/...passesgo test ./pkg/plugins/golang/v4/...passeskubebuilder create api --helpoutput reads well in a terminal