-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Support camelCase CSV output argument for file_name and save_interval. #2150
Conversation
This change adds support for camelCased versions of file_name and save_interval CSV output arguments, writing a warning to the logs informing users the older snake cased argument will be deprecated in time.
Codecov Report
@@ Coverage Diff @@
## master #2150 +/- ##
=========================================
Coverage ? 72.73%
=========================================
Files ? 184
Lines ? 14578
Branches ? 0
=========================================
Hits ? 10604
Misses ? 3331
Partials ? 643
Flags with carried forward coverage won't be shown. Click here to find out more. Continue to review full report at Codecov.
|
@@ -59,7 +60,7 @@ func (c Config) Apply(cfg Config) Config { | |||
} | |||
|
|||
// ParseArg takes an arg string and converts it to a config | |||
func ParseArg(arg string) (Config, error) { | |||
func ParseArg(arg string, logger *logrus.Logger) (Config, 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.
Do you have any thoughts on how we could avoid such a breaking change to the package's pubic API? Other options I was considering was:
- Use
Config
to indicate a soon to be deprecated argument was used, and write the log message further up the call stack where the logger is initialised (inoutput.go
) - Move the checking of the soon to be deprecated arguments to
output.go
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.
Hi, thanks for the PR!
Hhmm yeah, this is not ideal, but I think I prefer leaving it as is more than the alternatives, as currently it's clear that the warning happens where the configuration is assembled, and doing that validation outside of config.go
would muddy things a bit.
Other than that a package like warnings
might help, though it's not very idiomatic and we wouldn't want to add another dependency because of this. Maybe a custom error type that we can return and check for would be better.
So I'd say to leave it as is, unless someone from @grafana/k6-devs has a better idea.
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.
Okay, thanks @imiric
Hhmm yeah, this is not ideal, but I think I prefer leaving it as is more than the alternatives, as currently it's clear that the warning happens where the configuration is assembled, and doing that validation outside of config.go would muddy things a bit.
Yeah, I agree - this was my rational, it keeps the logic local. Interested to see what @grafana/k6-devs think.
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.
Perhaps, it makes sense to add this case (logging during config parsing) to #883 as "nice-to-have" to figure out how best to approach this if it comes up again?
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.
@yorugac Good idea, I've just added this as a nice to have to that issue. 👍
output/csv/config.go
Outdated
@@ -92,7 +99,8 @@ func ParseArg(arg string) (Config, error) { | |||
|
|||
// GetConsolidatedConfig combines {default config values + JSON config + | |||
// environment vars + arg config values}, and returns the final result. | |||
func GetConsolidatedConfig(jsonRawConf json.RawMessage, env map[string]string, arg string) (Config, error) { | |||
//nolint: lll |
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.
Passing the additional logger parameter causes the line length linting error, but given we're only passing the logger until people have migrated to the camel case version I felt the no lint comment would be sufficient for the time being.
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.
I in general prefer to split the func <name>(<arguments>) (<results>){
on three lines as in
func <name>(
<arguments>,
)(<results>){
as it keeps it more readable especially when lines start to wrap.
output/csv/config_test.go
Outdated
for arg, testCase := range cases { | ||
arg := arg | ||
testCase := testCase | ||
|
||
t.Run(arg, func(t *testing.T) { | ||
config, err := ParseArg(arg) | ||
config, err := ParseArg(arg, testLog) |
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.
This could've also tested that the warning is being logged
@mstoykov Thank you for the comments, I will get these addressed this evening. |
Co-authored-by: Mihail Stoykov <MStoykov@users.noreply.github.com>
69f2063
to
db885e7
Compare
db885e7
to
199248a
Compare
@mstoykov This is ready for a re-review when you can please. I've added an assertion over the expected log messages and level, and updated your other comments too. |
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.
LGTM
Hey @josephwoodward! Thank you so much for your contribution! Because it's Hacktoberfest we would love to send you a k6 swag pack to celebrate. I'll reacxh out to you separately! |
@FloorD That'd be great! Big fan of what everyone is doing at K6/Grafana so certainly wouldn't say no! |
This change adds support for camelCased versions of file_name and save_interval CSV output arguments,
writing a warning to the logs informing users the older snake cased argument will be deprecated in time.