NO-JIRA: Add /find-component-pattern command #15638
Conversation
Adds a command to analyze component usage patterns across the codebase, identify inconsistencies, and detect potential bugs. The command searches for all usages of a specified component, groups them into patterns, flags outliers (missing props, deprecated usage), and provides prioritized recommendations for standardization. Supports scoping to core components, specific packages, or all frontend code. Assisted-by Claude
|
@sg00dwin: This pull request explicitly references no jira issue. In response to this:
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 openshift-eng/jira-lifecycle-plugin repository. |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: sg00dwin The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
@sg00dwin: all tests passed! Full PR test history. Your PR dashboard. 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. I understand the commands that are listed here. |
| ``` | ||
| Which component would you like me analyze? | ||
|
|
||
| Use --scope=SCOPE to limit scope (optional): |
There was a problem hiding this comment.
Base on the examples at the end of the file this feel like is should be part of --help flag. Cause the user already specified the scope in the command, so rendering the usage, after the scope is defined does not sound as a correct flow.
| ``` | ||
| Which component would you like me analyze? | ||
|
|
||
| Use --scope=SCOPE to limit scope (optional): |
There was a problem hiding this comment.
Here the scope is already define, so the user should just specify the component name, right ?
| ## Usage | ||
|
|
||
| ``` | ||
| /find-component-pattern [--show-recommendations] [--scope=SCOPE] |
There was a problem hiding this comment.
Ideally if all the params could be supplied when triggering the cmd
| /find-component-pattern [--show-recommendations] [--scope=SCOPE] | |
| /find-component-pattern [component-name] [--show-recommendations] [--scope=SCOPE] |
|
|
||
| Use --scope=SCOPE to limit scope (optional): | ||
| - all - Search entire frontend (default) | ||
| - core - Only core components (frontend/public/components/) |
There was a problem hiding this comment.
thinking if we want to be more granular for a large packages, cause there could be hundreds of hits for a common resource.
Just a thought ... I've seen the Performance Considerations 👍
Summary
Adds
/find-component-patternslash command for analyzing component usage consistency across the OpenShift Console codebase.Features
--scope=all- Search entire frontend (default)--scope=core- Core components only--scope=package:NAME- Specific package--show-recommendationsflag)Use Cases