-
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
Report usages of the deprecated 'ext.loadimpact' option #4084
base: master
Are you sure you want to change the base?
Conversation
8c8bdf7
to
cd20b81
Compare
if err := lct.initRunner.SetOptions(configToReinject); err != nil { | ||
return nil, err | ||
} | ||
|
||
// Here, where we get the consolidated options, is where we check if any |
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 added it here because it looks like a considerably safe place among all the places configuration is read/written and manipulated in general, but any suggestion will be more than welcome.
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.
Also, note that this will be reported despite it's a local (k6 run
) or a remote execution (k6 cloud
), but I guess it's fine because a script that holds ext.loadimpact
is still a candidate of experiencing issues if we remove such support.
In any case, if we want to get more accurate metrics (only cloud executions), we can always account reports with this and a test run id.
// Here, where we get the consolidated options, is where we check if any | ||
// of the deprecated options is being used, and we report it. | ||
if _, isPresent := configToReinject.External["loadimpact"]; isPresent { | ||
if err := lct.preInitState.Usage.Strings("deprecated_options", "ext.loadimpact"); err != nil { |
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.
In https://github.com/grafana/k6/pull/4030/files the key is deprecations/<what is deprecated>
. I would prefer if we keep the keys more generic and deprecated_options
is very specific to options by the looks of it and I do not know of any other option that will make it relevant to have a separate key.
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.
So, is your suggestion: deprecations/ext.loadimpact
?
I'm happy with that one as well, sure!
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 guess that looks okay - yes. Don't know if we want options
somewhere in there, but as a one of case this seems good enough.
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, but would prefer if we change the key to be consistent
What?
It adds a new
deprecated_options
field into the usage reports, and accounts ifext.loadimpact
is still being used, and how often.Why?
Because we likely will remove that option parameter before v1, so we need to make some plans.
Checklist
make lint
) and all checks pass.make tests
) and all tests pass.Related PR(s)/Issue(s)
Related with https://github.com/grafana/k6-cloud/issues/2210