Skip to content
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

Merged
merged 7 commits into from
Oct 6, 2021

Conversation

josephwoodward
Copy link
Contributor

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.

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.
@CLAassistant
Copy link

CLAassistant commented Oct 1, 2021

CLA assistant check
All committers have signed the CLA.

@codecov-commenter
Copy link

codecov-commenter commented Oct 1, 2021

Codecov Report

❗ No coverage uploaded for pull request base (master@75d30e6). Click here to learn what that means.
The diff coverage is n/a.

❗ Current head 2f396e2 differs from pull request most recent head 8307029. Consider uploading reports for the commit 8307029 to get more accurate results
Impacted file tree graph

@@            Coverage Diff            @@
##             master    #2150   +/-   ##
=========================================
  Coverage          ?   72.73%           
=========================================
  Files             ?      184           
  Lines             ?    14578           
  Branches          ?        0           
=========================================
  Hits              ?    10604           
  Misses            ?     3331           
  Partials          ?      643           
Flag Coverage Δ
ubuntu 72.66% <0.00%> (?)
windows 72.37% <0.00%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.


Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 75d30e6...8307029. Read the comment docs.

@@ -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) {
Copy link
Contributor Author

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:

  1. 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 (in output.go)
  2. Move the checking of the soon to be deprecated arguments to output.go

Copy link
Contributor

@imiric imiric Oct 1, 2021

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.

Copy link
Contributor Author

@josephwoodward josephwoodward Oct 1, 2021

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.

Copy link
Contributor

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?

Copy link
Contributor Author

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. 👍

@@ -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
Copy link
Contributor Author

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.

Copy link
Contributor

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.

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)
Copy link
Contributor

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

output/csv/config.go Outdated Show resolved Hide resolved
@josephwoodward
Copy link
Contributor Author

josephwoodward commented Oct 4, 2021

@mstoykov Thank you for the comments, I will get these addressed this evening.

@mstoykov mstoykov added this to the v0.35.0 milestone Oct 4, 2021
@josephwoodward josephwoodward force-pushed the 2137-camelCaseCsv branch 2 times, most recently from 69f2063 to db885e7 Compare October 5, 2021 23:45
@josephwoodward
Copy link
Contributor Author

@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.

Copy link
Member

@inancgumus inancgumus left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@mstoykov mstoykov merged commit f76bfa5 into grafana:master Oct 6, 2021
@josephwoodward josephwoodward deleted the 2137-camelCaseCsv branch October 6, 2021 13:10
@FloorD
Copy link
Contributor

FloorD commented Oct 6, 2021

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!

@josephwoodward
Copy link
Contributor Author

@FloorD That'd be great! Big fan of what everyone is doing at K6/Grafana so certainly wouldn't say no!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants