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

Expose GCk6 test run ID via a JS API to the test script #4041

Open
andrewslotin opened this issue Nov 7, 2024 · 2 comments
Open

Expose GCk6 test run ID via a JS API to the test script #4041

andrewslotin opened this issue Nov 7, 2024 · 2 comments
Assignees
Labels

Comments

@andrewslotin
Copy link
Contributor

Whenever a k6 test is executed in Grafana Cloud using k6 cloud run or if Grafana Cloud is set as an output with k6 cloud run --local-execution, a test run ID is generated for that execution. This identifier is helpful for distinguishing between local runs, such as debugging a load test script, and cloud executions. It also aids in correlating requests made during the test run.

Currently, there is no reliable way to retrieve this value from within the test script code. To address this, I propose modifying the options.cloud object returned by k6/execution, adding a field that will be populated with the test run ID for the current execution.

@joanlopez
Copy link
Contributor

joanlopez commented Nov 7, 2024

Side-note; I'm not sure if now there's "a reliable way to retrieve this value from within the" (paraphrasing the sentence above) Go code (e.g. an extension or output), but I'd really love if we make that possible as well as part of this task, as that will unlock/make possible other ideas we have on the backlog.

In essence, being able to now the Test Run Id from Go code, either a normal "JavaScript" extension or from an "output" extension.

cc/ @Blinkuu this might be of your relevance, as this would be a blocker/requirement for the "Insights output" idea we discussed, as you need the Test Run ID to fetch the insights from the API.

cc/ @oleiade I see you assigned here, so ping me if you need further context.

@mstoykov
Copy link
Contributor

mstoykov commented Nov 8, 2024

@joanlopez the original proposal is about putting it in options.cloud and practically every part of k6 has access to the options. Which is why I proposed it like that internally, instead of coming up with another specific API.

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

No branches or pull requests

4 participants