The k6x builder service is an HTTP service that generates a k6 binary with the extensions specified in the request. The service is included in the k6x binary, so it can be started using the k6x service command.
The k6x builder service can be used independently, from the command line (e.g. using curl or wget commands), from a web browser, or from different subcommands of the k6x launcher as a builder called service.
Usage from the command line
The k6 binary can be easily built using wget , curl or other command-line http client by retrieving the appropriate builder service URL:
The builder service can be used from k6x using the --builder service flag:
k6x run --builder service script.js
k6x expects the address of the builder service in the environment variable called K6X_BUILDER_SERVICE. There is currently no default, it must be specified.
Simplified command line usage
In order to simplify use from the command line, the service also accepts version dependencies in any order. In this case, after unlocking the latest versions and sorting, the response will be an HTTP redirect.
The service serves HTTP GET requests, with a well-defined path structure:
htps://example.com/goos/goarch/dependency-list
Where goos is the usual operating system name in the go language (e.g. linux, windows, darwin), goarch is the usual processor architecture in the go language (e.g. amd64, arm64). The dependency-list is a comma-separated list of dependencies, in the following form:
name@version
Where name is the name of the dependency and version is the version number according to semver (with an optional leading v character). The first item in the list is always the dependency named k6, and the other items are sorted alphabetically by name. For example:
Based on the platform parameters (goos, goarch) and dependencies, the service prepares the k6 binary.
Since the response (the k6 binary) depends only on the request path, it can be easily cached. The service therefore sets a sufficiently long caching period (at least three month) in the response, as well as the usual cache headers (e.g. ETag). By placing a caching proxy in front of the service, it can be ensured that the actual k6 binary build takes place only once for each parameter combination.
The advantage of the solution is that the k6 binary is created on the fly, only for the parameter combinations that are actually used. Since the service preserves the go cache between builds, a specific build happens quickly enough.
Builder Service
The k6x builder service is an HTTP service that generates a k6 binary with the extensions specified in the request. The service is included in the k6x binary, so it can be started using the
k6x service
command.The k6x builder service can be used independently, from the command line (e.g. using
curl
orwget
commands), from aweb browser
, or from different subcommands of the k6x launcher as a builder calledservice
.Usage from the command line
The k6 binary can be easily built using wget , curl or other command-line http client by retrieving the appropriate builder service URL:
using wget
using curl
Usage from k6x
The builder service can be used from k6x using the
--builder service
flag:k6x expects the address of the builder service in the environment variable called
K6X_BUILDER_SERVICE
. There is currently no default, it must be specified.Simplified command line usage
In order to simplify use from the command line, the service also accepts version dependencies in any order. In this case, after unlocking the latest versions and sorting, the response will be an HTTP redirect.
using wget
using curl
How It Works
The service serves
HTTP GET
requests, with a well-defined path structure:Where
goos
is the usual operating system name in the go language (e.g.linux
,windows
,darwin
),goarch
is the usual processor architecture in the go language (e.g.amd64
,arm64
). Thedependency-list
is a comma-separated list of dependencies, in the following form:Where
name
is the name of the dependency andversion
is the version number according to semver (with an optional leadingv
character). The first item in the list is always the dependency namedk6
, and the other items are sorted alphabetically by name. For example:Based on the platform parameters (
goos
,goarch
) and dependencies, the service prepares the k6 binary.Since the response (the k6 binary) depends only on the request path, it can be easily cached. The service therefore sets a sufficiently long caching period (at least three month) in the response, as well as the usual cache headers (e.g.
ETag
). By placing a caching proxy in front of the service, it can be ensured that the actual k6 binary build takes place only once for each parameter combination.The advantage of the solution is that the k6 binary is created on the fly, only for the parameter combinations that are actually used. Since the service preserves the go cache between builds, a specific build happens quickly enough.