-
-
Notifications
You must be signed in to change notification settings - Fork 1k
fix: Deprecated flags msg for experimental command #4146
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
📝 WalkthroughWalkthroughThe changes enhance how deprecated flags are evaluated by introducing a new function type, Changes
Sequence Diagram(s)sequenceDiagram
participant Caller
participant Flag
participant EvaluateWrapper
participant EvalFunction
Caller->>Flag: Invoke RunAction
Flag->>EvaluateWrapper: Call evaluateWrapper(evalFn)
EvaluateWrapper->>EvaluateWrapper: Check if cli-redesign experiment enabled
alt Experiment enabled
EvaluateWrapper->>EvalFunction: Execute evalFn()
else Experiment disabled
EvaluateWrapper-->>Flag: Return nil (skip evaluation)
end
Flag-->>Caller: Complete action
Assessment against linked issues
Possibly related PRs
Suggested reviewers
✨ Finishing Touches
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
I don't really understand what's happening here. Do you mind adding some more documentation in the way of comments to explain the intention here? |
We discussed that if |
I don't think someone reading this: type EvaluateWrapperFunc func(ctx context.Context, evalFn func(ctx context.Context) error) error
// Flag is a wrapper for `cli.Flag` that avoids displaying deprecated flags in help, but registers their flag names and environment variables.
type Flag struct {
cli.Flag
evaluateWrapper EvaluateWrapperFunc
deprecatedFlags DeprecatedFlags
}
// NewFlag returns a new Flag instance.
func NewFlag(new cli.Flag, opts ...Option) *Flag {
flag := &Flag{
Flag: new,
evaluateWrapper: func(ctx context.Context, evalFn func(ctx context.Context) error) error {
return evalFn(ctx)
},
} Is going to know what |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 1
🔭 Outside diff range comments (1)
cli/flags/flag.go (1)
16-147
: 💡 Verification agent🧩 Analysis chain
Consider adding integration tests for the new evaluation wrapper functionality
The changes introduce a significant functional enhancement that could benefit from dedicated tests to verify the wrapper's behavior in different scenarios, especially with the experimental flag mentioned in the PR objectives.
🏁 Script executed:
#!/bin/bash # Check if there are tests for the new EvaluateWrapperFunc functionality echo "Searching for tests related to EvaluateWrapperFunc..." rg -l "EvaluateWrapperFunc" --type go echo "Searching for tests in the flags package..." rg -l "TestFlag|test.*Flag|flag.*Test" --type goLength of output: 617
Action: Add targeted integration tests for the evaluation wrapper functionality
While there are tests in the flags package (e.g. in
cli/flags/flag_test.go
and several integration tests under thetest/
directory), none appear to specifically exercise the new behavior introduced by theEvaluateWrapperFunc
. This wrapper is critical for controlling strict evaluation in scenarios involving deprecated flags. I recommend adding explicit integration tests that simulate:
- Cases where a custom evaluation wrapper modifies or intercepts the evaluation flow.
- Scenarios where the deprecated flag’s evaluation is invoked, ensuring that any modifications introduced by the wrapper are correctly handled.
- Error paths to confirm proper error propagation when the wrapper or the underlying evaluation function fails.
These tests will help ensure that the new functionality behaves as expected across different use cases.
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
cli/flags/flag.go
(4 hunks)cli/flags/global/flags.go
(3 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- cli/flags/global/flags.go
🧰 Additional context used
📓 Path-based instructions (1)
`**/*.go`: Review the Go code for quality and correctness. Make sure that the Go code follows best practices, is performant, and is easy to understand and maintain.
**/*.go
: Review the Go code for quality and correctness. Make sure that the Go code follows best practices, is performant, and is easy to understand and maintain.
cli/flags/flag.go
⏰ Context from checks skipped due to timeout of 90000ms (1)
- GitHub Check: Pull Request has non-contributor approval
🔇 Additional comments (5)
cli/flags/flag.go (5)
23-23
: LGTM! Added field for evaluation customizationThis field enables the customization of flag evaluation behavior, allowing for conditional messaging around deprecated flags.
31-33
: LGTM! Default implementation preserves original behaviorThe default implementation correctly maintains backward compatibility by simply executing the provided evaluation function without modification.
43-44
: LGTM! Enhanced flexibility with options patternThe updated
NewMovedFlag
function properly leverages the variadic options pattern, making the flag creation API more flexible and extensible.
131-131
: LGTM! Using the wrapper for deprecated flag evaluationCorrectly applies the evaluation wrapper to control how deprecated flags are evaluated.
147-147
: LGTM! Consistent wrapper usageThis change ensures consistent use of the evaluation wrapper pattern throughout the code, maintaining a uniform approach to flag evaluation.
// EvaluateWrapperFunc represents a function that is used to wrap the `Evaluate(ctx context.Context) error` strict control method. | ||
// Which can be passed as an option `WithEvaluateWrapper` to `NewFlag(...)` to control the behavior of strict control evaluation. | ||
type EvaluateWrapperFunc func(ctx context.Context, evalFn func(ctx context.Context) error) error |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🛠️ Refactor suggestion
Improve documentation for EvaluateWrapperFunc
The documentation explains the technical purpose of EvaluateWrapperFunc
, but lacks context about why someone would use this wrapper and specific use cases. According to the PR comments, this was designed to prevent deprecated messages from being displayed when the --experiment cli-redesign
flag is not specified.
// EvaluateWrapperFunc represents a function that is used to wrap the `Evaluate(ctx context.Context) error` strict control method.
// Which can be passed as an option `WithEvaluateWrapper` to `NewFlag(...)` to control the behavior of strict control evaluation.
+ // It's primarily used to conditionally show deprecated flag messages, especially when experimental features
+ // like the cli-redesign are enabled or disabled.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
// EvaluateWrapperFunc represents a function that is used to wrap the `Evaluate(ctx context.Context) error` strict control method. | |
// Which can be passed as an option `WithEvaluateWrapper` to `NewFlag(...)` to control the behavior of strict control evaluation. | |
type EvaluateWrapperFunc func(ctx context.Context, evalFn func(ctx context.Context) error) error | |
// EvaluateWrapperFunc represents a function that is used to wrap the `Evaluate(ctx context.Context) error` strict control method. | |
// Which can be passed as an option `WithEvaluateWrapper` to `NewFlag(...)` to control the behavior of strict control evaluation. | |
// It's primarily used to conditionally show deprecated flag messages, especially when experimental features | |
// like the cli-redesign are enabled or disabled. | |
type EvaluateWrapperFunc func(ctx context.Context, evalFn func(ctx context.Context) error) error |
Description
Fixes #4082.
TODOs
Read the Gruntwork contribution guidelines.
Release Notes (draft)
Added / Removed / Updated [X].
Migration Guide
Summary by CodeRabbit
New Features
Tests
Chores