k6/execution: add more information about the current test run

[na--]

This is a continuation of some of the things mentioned in #1320 that relate to information about the currently running test, but which were not implemented in the original k6/execution API that shipped in k6 v0.34.0.

#2093 adds a new k6/execution.test.abort() method, but we currently don't expose any of the information about the current test run in it. Some potentially useful things we could add expose there:

• the start time of the test run
• the total calculated test run duration (from the execution plan)
• the final consolidated script options? this seems cleaner than relying on the fact that we'll update the exported script options, and we've had a bunch of issues with that (see fix setting js options on the wrong object #1430)...
• other things like the whole runtime options? or at leasat parts of them - an alternative interface for accessing the environment variables will be much nicer than __ENV...
• the current working directory and file name - this should return the original ones when running archive bundle, but...
• ... there should be a way to tell if we're executing a JS file or a .tar archive bundle (which will be helpful as a proxy to determine if we're running the script locally or in the cloud)
• (somewhat unlikely) the execution segment sequence, though that is somewhat dependent on any new APIs from Data segmentation API framework #1539 and the actual instance execution segment should probably be in k6/execution.instance...

Some of these things will probably be useful in the init context as well (e.g. the CWD and env vars), so parts of k6/execution.test should definitely be accessible from the init context. Some parts, like the consolidated options or total test run duration, can't be available in the first init context execution (because it is the thing that actually gets the exported options...), but would be quite useful in subsequent VU initializations...

[imiric]

Just a note so that we don't make the same mistake from #1320: let's avoid suggesting features for the k6/execution API until we're sure that users actually want them. This is fine for cases where it actually solves an existing issue or makes a previously cumbersome workflow easier, but each addition is a change that possibly complicates things and something we'll have to maintain, so the leaner we can keep this API, the better.

[na--]

If you look at the old issue, a lot (most?) of these actually came from user requests. But yeah, in general, I agree and this is not a very high priority issue as of now. I'd appreciate any users to comment with their specific use cases here, that will help with us prioritizing it more highly.

[tom-miseur]

Regarding a "the current working directory and file name" use case: providing the LSN (Load Script Name) in the HTTP header for Dynatrace. However in this case, it is probably more useful (and appropriate) to pass in the already available execution.scenario.name.

The obvious workaround to not having access to the script name programmatically is to simply hardcode it, so generally speaking, I see it as low priority.

Querying the group name would be useful to populate the TSN (Test Step Name) field, however. We would of course need to think about what that would return when a HTTP request is fired from outside a group. I see this is being considered in #2260.

[geekflyer]

we need this to track usage of our 30-something load test scripts in order to identify unused ones and highly important ones.
We want to send some usage events to our logging system and need the filename of the script as identifier.
Since we want to (among other things) track local use of ad-hoc and user-maintained scripts, we can't really rely users to manually add the filename or path into the script but rather need a programmatic API that we can invoke via some commonly used reuse function.

[imiric]

@geekflyer As a workaround, could you set the filename in an environment variable and read it from the script?

For example:

// /tmp/test.js
export default function() {
  console.log('Script filename:', __ENV.FILENAME);
}

$ export FILENAME=/tmp/test.js
$ k6 run "$FILENAME"
[...]
INFO[0000] Script filename: /tmp/test.js                 source=console

[jalevin]

Hey all- I have a use case for this where I need to ensure that people contributing to tests are naming scenarios in a specific way. If it was possible to get the filename, I could set the scenario for them. Is this still on the roadmap?

[asher-dutchie]

I also really want to be able to identify the name of the current file. My test suite has grown fairly large and being able to do this would make it a lot easier to tie test scripts to configurations in a big YAML file.