-
Notifications
You must be signed in to change notification settings - Fork 1.4k
support community extensions #4922
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 community extensions #4922
Conversation
5456052
to
6eb7e09
Compare
6eb7e09
to
18cb212
Compare
00af9c1
to
337ddaf
Compare
Signed-off-by: Pablo Chacin <pablochacin@gmail.com>
Signed-off-by: Pablo Chacin <pablochacin@gmail.com>
5a17ece
to
8afaff8
Compare
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.
@pablochacin unit tests are missing here
cmd/state/state.go
Outdated
// DefaultBuildServiceURL defines the URL to the default (grafana hosted) build service | ||
DefaultBuildServiceURL = "https://ingest.k6.io/builder/api/v1" | ||
// CloudExtensionsCatalog defines the extensions catalog for cloud supported extensions | ||
CloudExtensionsCatalog = "cloud" | ||
// CommunityExtensionsCatalog defines the extensions catalog for community extensions | ||
CommunityExtensionsCatalog = "oss" |
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.
Is it required to have them exported?
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.
They are referenced in internal/cmd/launcher.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.
But they aren't used here, no?
Do we need to define and export them here? Just out of curiosity.
What kind of tests are you thinking? The main impact of this changes are internal to the |
We should assert the URL generated if the community extensions are enabled. So the new logic added. |
internal/cmd/launcher.go
Outdated
buildSrv := p.gs.Flags.BuildServiceURL | ||
buildSrvURL, err := url.Parse(buildSrv) | ||
if err != nil { | ||
return nil, fmt.Errorf("invalid URL to binary provisioning build service: %w", err) | ||
} | ||
|
||
catalog := state.CloudExtensionsCatalog | ||
if p.gs.Flags.EnableCommunityExtensions { | ||
catalog = state.CommunityExtensionsCatalog | ||
} | ||
buildSrv = buildSrvURL.JoinPath(catalog).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.
We might consider moving this logic into a dedicated function that accepts as input a flagset and it returns the URL or an error.
In this way, it's easier to test.
Signed-off-by: Pablo Chacin <pablochacin@gmail.com>
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, just one missing improvement
internal/cmd/launcher_test.go
Outdated
buildSrvURL: state.DefaultBuildServiceURL, | ||
enableCommunityExtensions: false, | ||
expectErr: false, | ||
expected: fmt.Sprintf("%s/%s", state.DefaultBuildServiceURL, state.CloudExtensionsCatalog), |
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.
Let's use a static string here. For example, if we wrote a bad value in state.CloudExtensionsCatalog
then we wouldn't be able to catch it. Because the assertion is depending on the past value.
expected: fmt.Sprintf("%s/%s", state.DefaultBuildServiceURL, state.CloudExtensionsCatalog), | |
expected: "http://my-fake-exected-url/path-of-the-community, |
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.
Yeah, I'm generally in favor of the practice @codebien is suggesting here, so if anytime we change that value, it will be more explicit, and likely easier to catch potential breaking changes, etc 👍🏻
internal/cmd/launcher_test.go
Outdated
if !tc.expectErr && err != nil { | ||
t.Fatalf("unexpected error %v", err) | ||
} | ||
|
||
if tc.expectErr && err == nil { | ||
t.Fatalf("expected error got none") | ||
} | ||
|
||
if !tc.expectErr && buildSrvURL != tc.expected { | ||
t.Fatalf("expected buildSrvURL %q got %q", tc.expected, buildSrvURL) | ||
} |
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.
Nit; I think we generally use assert
or require
from testify 🤔
Signed-off-by: Pablo Chacin <pablochacin@gmail.com>
Signed-off-by: Pablo Chacin <pablochacin@gmail.com>
internal/cmd/launcher_test.go
Outdated
buildSrvURL string | ||
enableCommunityExtensions bool | ||
expectErr bool | ||
expected 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.
expected string | |
expectURL string |
To be consistent with the error field
Signed-off-by: Pablo Chacin <pablochacin@gmail.com>
76dd822
into
binary-provisioning/enable-to-all-users
What?
Allow users to opt for using community extensions (defined in the
oss
catalog) with theK6_ENABLE_COMMUNITY_EXTENSIONS
environment variable. If not enabled, the defaultcloud
catalog will be used.Why?
By default, binary provisioning only supports extensions defined in the
cloud
catalog.We want to offer users the possibility of opting in for the complete catalog of extensions when running tests locally.
Note: if the user enables the community extensions and sends a test to the cloud using
cloud run
, the test will fail at execution time, as the cloud runners do not support these extensions.Checklist
make check
) and all pass.Checklist: Documentation (only for k6 maintainers and if relevant)
Please do not merge this PR until the following items are filled out.
Related PR(s)/Issue(s)
Closes #4884