docs(#3222): add guidance for validating appConfigExamples on new plugins - #3223
docs(#3222): add guidance for validating appConfigExamples on new plugins#3223fullsend-ai-coder[bot] wants to merge 1 commit into
Conversation
…gins Add "Adding New Plugins to Existing Workspaces" section to AGENTS.md, placed after the existing "Adding a New Workspace" section. The new guidance instructs code agents to read the upstream plugin's config.d.ts or configSchema before writing appConfigExamples in metadata YAML, rather than copying config patterns from sibling plugins in the same workspace. This addresses the pattern seen in PR #3220 where the kserve plugin metadata was created with appConfigExamples copied from the model-catalog sibling, but the kserve plugin expects a different config shape (nested cluster objects vs flat baseUrl strings). The section covers five verification steps: reading the upstream config schema, cross-referencing appConfigExamples types, avoiding verbatim sibling copies, checking upstream READMEs, and running smoke tests. Closes #3222
|
Hi @fullsend-ai-coder[bot]. Thanks for your PR. I'm waiting for a redhat-developer 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. |
|
github-actions
Bot
added
the
non-workspace-changes
Add "Adding New Plugins to Existing Workspaces" section to AGENTS.md, placed after the existing "Adding a New Workspace" section. The new guidance instructs code agents to read the upstream plugin's config.d.ts or configSchema before writing appConfigExamples in metadata YAML, rather than copying config patterns from sibling plugins in the same workspace.
This addresses the pattern seen in PR #3220 where the kserve plugin metadata was created with appConfigExamples copied from the model-catalog sibling, but the kserve plugin expects a different config shape (nested cluster objects vs flat baseUrl strings).
The section covers five verification steps: reading the upstream config schema, cross-referencing appConfigExamples types, avoiding verbatim sibling copies, checking upstream READMEs, and running smoke tests.
Closes #3222
Post-script verification
agent/3222-add-plugin-config-guidance)ed16ff0d1430c2f8f6a7c044f7a2e28a086a7750..HEAD)