Important
The k6x is under refactor. This documentation is about the refactored code. Previous documentation is marked with the before-grafana git tag. The last release before the refactor is v0.4.0.
Run k6 with extensions
Run k6 with a seamless extension user experience.
k6x is a k6 launcher that automatically provides k6 with the extensions used by the test. In order to do this, it analyzes the script arguments of the run and archive subcommands, detects the extensions to be used and their version constraints.
The launcher acts as a drop-in replacement for the k6 command. For more convenient use, it is advisable to create an alias or shell script called k6 for the launcher. The alias can be used in exactly the same way as the k6 command, with the difference that it generates the real k6 on the fly based on the extensions you want to use.
Any k6 command can be used. Use the help command to list the available k6 commands.
Since k6x tries to emulate the k6 command line, the help command or the --help flag cannot be used to display help from k6x command itself. The k6x help can be displayed using the --usage flag:
k6x --usage
k6x tries to provide the appropriate k6 executable after detecting the extension dependencies. This can be done using a build service or a native builder.
No additional installation is required to use the build service, just provide the build service URL.
The build service URL can be specified in the K6_BUILD_SERVICE_URL environment variable or by using the --build-service-url flag.
There is no default URL for the build service, otherwise k6x will automatically provide k6 with the native builder.
To use the native builder, you only need to install the Go language toolkit.
The native builder uses a k6 extension catalog to resolve extension URLs and versions. The extension catalog URL has a default value. A different extension catalog URL can be specified in the K6_EXTENSION_CATALOG_URL environment variable or by using the --extension-catalog-url flag.
Version constraints can be specified using the JavaScript "use ..." pragma syntax for k6 and extensions. Put the following lines at the beginning of the test script:
"use k6 >= v0.52";
"use k6 with k6/x/faker > 0.2";Any number of "use k6" pragmas can be used.
Note The use of pragmas is completely optional for JavaScript type extensions, it is only necessary if you want to specify version constraints.
The pragma syntax can also be used to specify an extension dependency that is not referenced in an import expression. A typical example of this is the Output type extension such as xk6-top:
"use k6 with top >= 0.1";Read the version constraints syntax in the Version Constraints section
The extensions to be used and optionally their version constraints can also be specified in the K6_DEPENDENCIES environment variable. The value of the environment variable K6_DEPENDENCIES is a list of elements separated by semicolons. Each element specifies an extension (or k6 itself) and optionally its version constraint.
k6>=0.52;k6/x/faker>=0.3;k6/x/sql>=0.4
The manifest file is a JSON file, the dependencies property of which can specify extension dependencies and version constraints. The value of the dependencies property is a JSON object. The property names of this object are the extension names (or k6) and the values are the version constraints.
{
"dependencies": {
"k6": ">=0.52",
"k6/x/faker": ">=0.3",
"k6/x/sql": ">=0.4"
}
}The manifest file is a file named package.json, which is located closest to the k6 test script or the current directory, depending on whether the given subcommand has a test script argument (e.g. run, archive) or not (e.g. version). The package.json file is searched for up to the root of the directory hierarchy.
Version constraints can be specified in several sources (pragma, environment, manifest) but cannot be overwritten. That is, for a given extension, the version constraints from different sources must either be equal, or only one source can contain a version constraint.
This section is based on the Masterminds/semver documentation.
There are two elements to the comparisons. First, a comparison string is a list
of space or comma separated AND comparisons. These are then separated by || (OR)
comparisons. For example, ">= 1.2 < 3.0.0 || >= 4.2.3" is looking for a
comparison that's greater than or equal to 1.2 and less than 3.0.0 or is
greater than or equal to 4.2.3.
The basic comparisons are:
=: equal (aliased to no operator)!=: not equal>: greater than<: less than>=: greater than or equal to<=: less than or equal to
There are multiple methods to handle ranges and the first is hyphens ranges. These look like:
1.2 - 1.4.5which is equivalent to>= 1.2 <= 1.4.52.3.4 - 4.5which is equivalent to>= 2.3.4 <= 4.5
The x, X, and * characters can be used as a wildcard character. This works
for all comparison operators. When used on the = operator it falls
back to the patch level comparison (see tilde below). For example,
1.2.xis equivalent to>= 1.2.0, < 1.3.0>= 1.2.xis equivalent to>= 1.2.0<= 2.xis equivalent to< 3*is equivalent to>= 0.0.0
The tilde (~) comparison operator is for patch level ranges when a minor
version is specified and major level changes when the minor number is missing.
For example,
~1.2.3is equivalent to>= 1.2.3, < 1.3.0~1is equivalent to>= 1, < 2~2.3is equivalent to>= 2.3, < 2.4~1.2.xis equivalent to>= 1.2.0, < 1.3.0~1.xis equivalent to>= 1, < 2
The caret (^) comparison operator is for major level changes once a stable
(1.0.0) release has occurred. Prior to a 1.0.0 release the minor versions acts
as the API stability level. This is useful when comparisons of API versions as a
major change is API breaking. For example,
^1.2.3is equivalent to>= 1.2.3, < 2.0.0^1.2.xis equivalent to>= 1.2.0, < 2.0.0^2.3is equivalent to>= 2.3, < 3^2.xis equivalent to>= 2.0.0, < 3^0.2.3is equivalent to>=0.2.3 <0.3.0^0.2is equivalent to>=0.2.0 <0.3.0^0.0.3is equivalent to>=0.0.3 <0.0.4^0.0is equivalent to>=0.0.0 <0.1.0^0is equivalent to>=0.0.0 <1.0.0
k6x [flags] [command]
--build-service-url string URL of the k6 build service to be used
--extension-catalog-url string URL of the k6 extension catalog to be used
-h, --help help for k6
--no-color disable colored output
-q, --quiet disable progress updates
--usage print launcher usage
-v, --verbose enable verbose logging
k6x run script.jsThat's all!
script.js
import { Faker } from "k6/x/faker";
import sql from "k6/x/sql";
const db = sql.open("sqlite3", "./test-users.db");
export function setup() {
db.exec(`
CREATE TABLE IF NOT EXISTS users (
sub varchar PRIMARY KEY,
name varchar NOT NULL,
email varchar NOT NULL
);`);
const faker = new Faker(11);
db.exec(`
INSERT OR REPLACE INTO users (sub, name, email) VALUES (
'${faker.internet.username()}',
'${faker.person.firstName()} ${faker.person.lastName()}',
'${faker.person.email()}'
);`);
}
export function teardown() {
db.close();
}
export default function () {
const results = sql.query(db, "SELECT * FROM users");
for (const row of results) {
const { sub, name, email } = row;
console.log({ sub, name, email });
}
}Precompiled binaries can be downloaded and installed from the Releases page.
If you have a go development environment, the installation can also be done with the following command:
go install github.com/grafana/k6x@latest
The launcher acts as a drop-in replacement for the k6 command. For more convenient use, it is advisable to create an alias or shell script called k6 for the launcher. The alias can be used in exactly the same way as the k6 command, with the difference that it generates the real k6 on the fly based on the extensions you want to use.
If you want to contribute, please read the CONTRIBUTING.md file.
This section contains a description of the tasks performed during development. Commands must be issued in the repository base directory. If you have the xc command-line tool, individual tasks can be executed simply by using the xc task-name command in the repository base directory.
Click to expand
Update documentation in README.md.
go run ./tools/gendoc README.mdRun the static analyzer.
We make use of the golangci-lint tool to lint the code in CI. The actual version you can find in our .golangci.yml.
golangci-lint runRun the tests.
To exercise the entire test suite, please run the following command
go test -count 1 -race -coverprofile=build/coverage.txt ./...View the test coverage report.
go tool cover -html=build/coverage.txtBuild the executable binary.
This is the easiest way to create an executable binary (although the release process uses the goreleaser tool to create release versions).
go build -ldflags="-w -s" -o k6x .Creating an executable binary with a snapshot version.
The goreleaser command-line tool is used during the release process. During development, it is advisable to create binaries with the same tool from time to time.
goreleaser build --snapshot --clean --single-target -o k6xBuilding a Docker image. Before building the image, it is advisable to perform a snapshot build using goreleaser. To build the image, it is advisable to use the same Docker.goreleaser file that goreleaser uses during release.
Requires: snapshot
docker build -t grafana/k6x -f Dockerfile.goreleaser .Run all scripts in the examples directory with a fresh build.
Requires: clean, snapshot
find examples -type f | xargs -n 1 ./k6x runDelete the build directory.
rm -rf build