-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Provide a file storing API #3017
Comments
👍 in general, though this is definitely deep
We don't need to figure out all of these things and have a perfect holistic design at the start. However, we should at least consider them carefully, and we should ensure that any public options or APIs we expose to users don't tie our hands and prevent us from implementing a better and more complete solution in the future. For example, |
Thanks for your quick response @na-- ! In regards of the points you mentioned:
Yes, I thought maybe
Absolutely, that was a kind of biased comment based on screenshots functionality, but I also made a comment that we probably want to use some some reader abstraction that allows us to read and upload the file in chunks so we can work with large files in the future 👍
I think that makes sense.
That's a very good point. Initially I thought on keeping this simple, but I can definitely see use cases to extend this, for example to use different authentication mechanisms with the remote storage than the ones implemented by default in k6, or some other constraints that users might require to upload test related files to their own storage directly 👍
Agree, I'm not much sold on |
Feature Description
Many times extensions might want to store files associated with the test run. For example, in the case of k6 browser, the user has the capability of taking screenshots of the test execution and store them as a file in FS. Currently this functionality is delegated to the extensions implementation, but it would probably make sense to centralize the file storing functionality in k6 and expose its API to extensions.
There are a couple of benefits that I can think for this:
In future iterations, this API could possibly be also exposed to the JS API.
Suggested Solution (optional)
From the options perspective, there could be a new option specifically to toggle the files storing functionality, for example between
local
(default) andcloud
. E.g.:Maybe some restrictions should apply to this option in sync with
--out
option. E.g.: File storing option can only be set tocloud
if metrics output option is also set to the cloud.From the Go API perspective, a simple API can be exposed in order to handle file storing functionality associated with the test run. E.g.:
Path will contain the path and name for the file. In this case, if k6 is running with
--files cloud
option, the path might be ignored or be used as a "key" for the remote storing platform.Already existing or connected issues / PRs (optional)
Superseeds grafana/xk6-browser#839
The text was updated successfully, but these errors were encountered: