Add default case to handle invalid --output flag in version command

[kfess]

Description

Add default case for invalid --output flag in version command

When users specify an invalid value for the --output flag (e.g., --output=yml),
the command fails silently with no error message or output.

This PR adds a default case to the switch statement that returns a clear error message,
matching the error handling pattern used in kubectl version.

Output after adding default block

$ kustomize version --output=yml
Error: --output must be 'yaml' or 'json'
Usage:
  kustomize version [flags]

Examples:
kustomize version

Flags:
  -h, --help            help for version
  -o, --output string   One of 'yaml' or 'json'.

Global Flags:
      --stack-trace   print a stack-trace on error

exit status 1

Fixes #6032

Additional context

This is my first contribution to the kustomize codebase.
Please let me know if there's anything I should adjust to better align with the project's conventions.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: kfess
Once this PR has been reviewed and has the lgtm label, please assign varshaprasad96 for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[koba1t]

Hi @kfess
Thanks for your contribution!

When fixing a bug, please add sufficient test cases to verify the fix and prevent regressions。

[kfess]

@koba1t
Thank you for the feedback. I will add test cases to verify the fix and prevent regressions.
Please review them once I've updated the PR.

[kfess]

@koba1t

I'd like to confirm the expected error output behavior when an invalid --output value is provided.

Current behavior

kubectl:

$ kubectl version --output=yml
error: --output must be 'yaml' or 'json'

kustomize (current behavior shows help text as well):

$ kustomize version --output=yml
Error: --output must be 'yaml' or 'json'
Usage:
  kustomize version [flags]
Examples:
kustomize version
Flags:
  -h, --help            help for version
  -o, --output string   One of 'yaml' or 'json'.
Global Flags:
      --stack-trace   print a stack-trace on error
exit status 1

I believe the kubectl behavior (showing only the error message without the usage/help text) is better for this case.
Is this understanding correct? Should I modify my PR to suppress the usage output on validation errors, matching kubectl's behavior and add test for it?

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all PRs.

This bot triages PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the PR is closed

You can:

• Mark this PR as fresh with /remove-lifecycle stale
• Close this PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[venkatasai-kadamati]

Thanks for the work on this @kfess — the fix direction is correct.

A few things to address before this can be merged per the contribution guidelines:

1. Two-commit requirement: Bug fix PRs must have exactly two commits — commit 1 adds a failing test demonstrating the incorrect behavior, commit 2 adds the fix. A single commit with no tests won't pass review.
2. Missing tests: The fix has no accompanying version_test.go. The guidelines explicitly state: "Regression test is absolutely required; cannot accept bug fixes without tests."
3. Validation placement: The check is placed in Run(). Since Validate() already handles the --short/--output mutual-exclusion case, the output-format validation belongs there too — and a matching default: case in Run() should be added as a defensive guard for direct callers.

I'm working on a PR that addresses all three — happy to coordinate if you want to incorporate these changes into your branch instead.

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all PRs.

This bot triages PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the PR is closed

You can:

• Mark this PR as fresh with /remove-lifecycle rotten
• Close this PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the PR is closed

You can:

• Reopen this PR with /reopen
• Mark this PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close

[k8s-ci-robot]

@k8s-triage-robot: Closed this PR.

Details

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the PR is closed

You can:

• Reopen this PR with /reopen
• Mark this PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close

Instructions 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.

[koba1t]

/reopen

[kubernetes-prow]

@koba1t: Reopened this PR.

Details

In response to this:

/reopen

Instructions 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.

[kubernetes-prow]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: kfess
Once this PR has been reviewed and has the lgtm label, please assign varshaprasad96 for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[koba1t]

@kfess
I apologize for the late reply.

error output behavior

I think it would be best to match the kubectl behavior.