new plugin schemagen v0.3.0

[ogormans-deptstack]

Multi-subcommand kubectl plugin driven by the cluster's OpenAPI v3 schema.

Three subcommands:

• manifest - generate example YAML for any resource type or CRD
• migrate - check manifests for deprecated or removed APIs
• scaffold - generate kustomize bases from resource schemas

Tested with kubectl krew install --manifest=plugins/schemagen.yaml --archive=... locally.

Plugin repo: https://github.com/ogormans-deptstack/kubectl-schemagen

[ahmetb]

🤖 Beep beep! I’m a robot speaking on behalf of @ahmetb. 🤖

---

Thanks for submitting your kubectl plugin to Krew!
One of the krew-index maintainers will review it soon. Note that the reviews for new plugin submissions may take a few days.

In the meanwhile, here are a few tips to make your plugin manifest better:

• Make sure your plugin follows the best practices.
• Eliminate redundant wording form shortDescription (it should be max 50 characters).
• Try to word wrap your description to 80-character lines (no usage examples, please).

Thanks for your patience!
/kind new-plugin

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: ogormans-deptstack
Once this PR has been reviewed and has the lgtm label, please assign chriskim06 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

[ahmetb]

Thanks for submitting schemagen! A few notes for your awareness:

Review timeline: Initial plugin submissions can take quite some time to review — the maintainers are currently receiving a high volume of submissions (including many vibe-coded plugins) and review this index on a best-effort basis. Please be patient and refrain from directly pinging reviewers.

Reviewer assessment: Reviewers will assess whether the plugin is a good fit for the index and whether its functionality is already covered by existing plugins.

Potentially similar existing plugins: The three subcommands in schemagen overlap with functionality already available in the index:

• manifest subcommand (generate example YAML for any resource type or CRD) is similar to:

  • example — prints example manifest YAMLs for a given resource type
  • creyaml — generates custom resource YAML manifests from CRD schemas

• migrate subcommand (check manifests for deprecated or removed APIs) is similar to:

  • deprecations — checks for deprecated/removed objects in a cluster

We encourage you to try out these existing plugins and consider whether schemagen's functionality would be better contributed upstream to one of them. If your tool offers meaningfully differentiated value (e.g., the scaffold subcommand generating kustomize bases from schemas appears to be novel), it may be worth highlighting that distinction clearly in your submission.

---

Generated by Claude Code

[ogormans-deptstack]

Fair points, and I genuinely appreciate the thorough review here. Taking the time to map each subcommand against existing plugins in the index is really helpful, especially for someone still finding their way around the krew ecosystem. I wasn't aware of creyaml or deprecations.

Happy to drop the manifest subcommand entirely since example and creyaml already cover that space. The original design had it as a building block for scaffold, but scaffold can generate its own YAML internally without exposing that as a user-facing command.

On migrate: worth noting it doesn't actually perform any migration. It reads YAML files and reports which API versions are deprecated or removed against the live cluster's discovery API. The intent was as a companion to scaffold (generate a kustomize base, then check your existing manifests against the cluster). But if deprecations already fills that gap well enough, I'm open to cutting it too.

So the question from my side: does it make more sense to slim this down to just the scaffold functionality (kustomize base generation from OpenAPI schemas, which seems to be the novel bit), or is there value in keeping migrate alongside it as a workflow pair? Happy to go either way.

---

Generated by Claude Code

[ahmetb]

see #5610 #5534 too
#5611 (comment)

[ahmetb]

It's up to you either way. If you can show there's unique functionality, I'm happy to accept this. Overlapped parts are just bad to have as you can tell your users to use another plugin to achieve those parts instead of reimplementing/maintaining them.