-
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
add extension version #2754
add extension version #2754
Conversation
Hey @HarrisChu, Please, check this previous comment where we shared our vision regarding this feature. |
perfect for me. |
If you would like to contribute then you can keep this open and address it as a request change. |
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.
Thanks for this PR @HarrisChu! 🙇
We've had #1741 in our backlog for a long time, so it's great that it's finally being implemented. As you've found, it's an important feature for k6 extension maintainers.
I do have a couple of requirements before merging this. Namely making the k6 run
output more pleasing, and also showing the versions of any output extensions. The others are suggestions that would be nice to have, but not blockers.
Since testing this is a bit tricky, we might want to have an E2E test instead. Currently we have an xk6
CI workflow, so it might make sense to add an assertion or two about the actual output of both k6 run
and k6 version
there. Unless someone has a better idea to test this...
return c.Sprint(consts.Banner()) | ||
banner := make([]string, 0, len(modules.GetJSModuleVersions())+1) | ||
|
||
banner = append(banner, consts.Banner()) | ||
for pkg, version := range modules.GetJSModuleVersions() { | ||
banner = append(banner, fmt.Sprintf("extension %s %s", pkg, version)) | ||
} | ||
return c.Sprint(strings.Join(banner, "\n")) |
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 think this output needs to be a bit more visually pleasing. Here's what it currently looks like:
The extension information shouldn't be part of the banner. The banner itself is only reserved for... well, the k6.io banner 😄
Instead, if we do want to include this information as part of the k6 run
output in addition to the k6 version
output (I do think it makes sense to have it in both places), then let's integrate it into the section below the banner, as suggested in #1741.
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.
ok
for path, version := range modules.GetJSModuleVersions() { | ||
printToStdout(globalState, fmt.Sprintf("extension %s %s\n", path, version)) | ||
} |
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.
k6 supports both JS and output extensions. So we should make sure that both are shown in this output (same goes for the k6 run
output).
You can test by building a binary with an output extension, e.g.:
XK6_K6_REPO=github.com/HarrisChu/k6 xk6 build master \
--with github.com/vesoft-inc/k6-plugin \
--with github.com/grafana/xk6-output-influxdb
It should be a matter of doing something similar as in js/modules/modules.go
and calling getPackageVersion(mod)
from output.RegisterExtension()
. You'll probably want to move getPackageVersion()
somewhere where it's accessible by both (maybe lib/extensions.go
?).
modules = make(map[string]interface{}) | ||
moduleVersions = make(map[string]string) |
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.
Would it make sense to reuse the modules
map, and have its values be a small struct like:
type module struct {
mod interface{}
version string
}
This way getPackageVersion()
would only return the version, as its name implies, and not also set (another) global map value.
This will complicate things slightly, as you'll need to change wherever GetJSModules()
is called (or change GetJSModules()
itself to continue to return just the modules without the version; though I think the first approach is slightly better), but it should avoid the repetition, and be a bit cleaner in the end. It would also avoid the need for a separate GetJSModuleVersions()
function.
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.
looks good
getPackageVersion(mod) | ||
} | ||
|
||
func getPackageVersion(mod interface{}) { |
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.
func getPackageVersion(mod interface{}) { | |
func getModuleVersion(mod interface{}) { |
I think this is slightly clearer, as we are getting the Go module version after all (and the map is called moduleVersions
).
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.
good catch.
btw, If a package has two modules, it just has one package in map.
how about display the module name? e.g.
extensions: github.com/dgzlopes/k6-extension-notifications k6/x/ext1 v1.0.0
github.com/dgzlopes/k6-extension-notifications k6/x/ext2 v1.0.0
Codecov Report
@@ Coverage Diff @@
## master #2754 +/- ##
==========================================
- Coverage 75.59% 75.55% -0.04%
==========================================
Files 202 205 +3
Lines 15992 16427 +435
==========================================
+ Hits 12089 12412 +323
- Misses 3151 3244 +93
- Partials 752 771 +19
Flags with carried forward coverage won't be shown. Click here to find out more.
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
Hi @HarrisChu, are you available to finish the work on the pending items? We'd like to release this in the upcoming v0.42.0, so this should be merged in the next week or two. If not, that's OK as well, and someone from our side would pick it up. You'd still get credit in the release notes, of course 🙂 |
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 align with the comments and recommendations of @imiric 🙏🏻
Really good work though, looking forward to see those comments addressed 👍🏻
Co-authored-by: HarrisChu <[email protected]> This adds some structure and extracts common functionality for registering and retrieving extension information into a standalone package. Partly based on the work and feedback in #2754.
Closing this since it was superseded by #2805. Thanks again for your contribution @HarrisChu! 🙇 |
Co-authored-by: HarrisChu <[email protected]> This adds some structure and extracts common functionality for registering and retrieving extension information into a standalone package. Partly based on the work and feedback in #2754.
Co-authored-by: HarrisChu <[email protected]> This adds some structure and extracts common functionality for registering and retrieving extension information into a standalone package. Partly based on the work and feedback in #2754.
Co-authored-by: HarrisChu <[email protected]> This adds some structure and extracts common functionality for registering and retrieving extension information into a standalone package. Partly based on the work and feedback in #2754.
sorry, I had some emergencies... |
@HarrisChu No problem. It didn't make it in v0.42.0, but it will be released in v0.43.0 a few weeks from now. |
I write a k6 extension and build with xk6, but I cannot know the extension version via command line.
if extension module implement
VersionGetter
interface, could display via version command.