v0.1.33

k6registry v0.1.33 is here 🎉!

This is an internal maintenance release.

• Update k6lint to v0.2.0
• Compliance check TTL

k6lint v0.2.0

k6lint v0.2.0 includes two new checkers:

• build checker
• smoke checker

build checker

The check is successful if the extension can be built with the latest k6 release.

smoke checker

The check is successful if there is a smoke test script and it runs successfully with the k6 built with the extension.

Obviously, a prerequisite for a successful run is that the build checker runs successfully, otherwise k6 cannot be built with the extension.

The smoke test script file is searched for in the root of the repository and in the test,tests,examples directories. The name of the smoke test script is one of the following:

• smoke.js
• smoke.ts
• smoke.test.js
• smoke.test.ts

Compliance check TTL

The result of the compliance check was previously cached until the source code of the given extension was changed.

The result of the build check depends not only on the source code of the given extension, but also on the latest k6 release. This made it necessary to introduce a TTL (time to live) value in the compliance check cache.

v0.1.32

k6registry v0.1.32 is here 🎉!

This is an internal maintenance release.

xk6 topic not required for internal extensions

The internal linter previously expected the xk6 topic to be set on the extensions repository. In the case of internal (albeit public) extensions, it would not be a good idea to use the xk6 topic, because that would cause them to appear in the GitHub topic search.

The internal linter now does not expect the xk6 topic to be set for extensions that do not have oss in their products property. That is, in the case of extensions that cannot be used in Grafana k6, the use of the xk6 topic is not required.

v0.1.30

k6registry v0.1.30 is here 🎉!

This is an internal maintenance release.

Improving the registry schema

• The new cgo property indicates that building the extension requires cgo to be enabled.
• In the products property, synthetic specifies Synthetic Monitoring product.

v0.1.29

k6registry v0.1.29 is here 🎉!

This is an internal maintenance release.

Generate catalog and registry at the same time

During customization, it is often necessary to generate both catalog and registry. These two outputs can now be generated simultaneously, with a single k6registry run.

The --catalog flag now specifies the location of the generated catalog.

v0.1.28

k6registry v0.1.28 is here 🎉!

This is an internal maintenance release.

Add version constraints support

Version constraints are primarily used to filter automatically detected versions. It can also be used to filter the versions property imported from the origin registry.

v0.1.27

k6registry v0.1.27 is here 🎉!

This is an internal maintenance release.

• Support for manual version number configuration
• Update versions from arbitrary git repository

Support for manual version number configuration

Instead of using the repository manager API, it is possible to manually configure the versions of the extensions. The API of the less common repository managers is not worth supporting, on the other hand, in some cases it may be necessary to control the allowed versions.

If the versions property is specified for an extension in the registry source, it overwrites the automatic version detection.

Update versions from arbitrary git repository

The API of the less common repository managers is not worth supporting, rather the available version numbers are detected with local git operations after cloning/pulling the git repository.

The cache directory used for compliance checks, where the git repositories are kept up-to-date, is also used to detect versions (tags).

Support for import extension properties from other registry

When creating a custom registry, it is inconvenient (and a potential source of error) to duplicate the data of those extensions that are also included in the registry maintained by Grafana. Support for importing extension data from other registries helps with this.

An optional origin registry URL can be specified with the --origin command line flag. If the extension is included in the origin registry, the default values ​​of its properties will be the values ​​specified in the origin registry. To import all the properties, it is enough to specify the module property. Properties in the origin registry can be overwritten in the registry source. For example, by specifying the versions property, you can specify that only certain versions are included in the generated registry.

v0.1.26

k6registry v0.1.26 is here 🎉!

This is an internal maintenance release.

Fix change detection

The use of the out parameter was a prerequisite for change detection in GitHub Actions mode. If the api parameter is used, the out parameter is not required. As a result, when using the api parameter, change detection did not work until now. This issue is fixed in this release. Change detection now works when using the api parameter in GitHub Actions mode.

v0.1.25

k6registry v0.1.25 is here 🎉!

This is an internal maintenance release.

Added testability of generated files

The generated registry and catalog will play an important role in the k6 binary provisioning subsystem, so it is important that there is no loss of service due to generated files. It is advisable to test the generated files to see if they meet the minimum requirements.

The --test flag can be used to test registry and catalog files generated with the --api flag. The test is successful if the file is not empty, contains k6 and at least one extension, and if all extensions meet the minimum requirements (e.g. it has versions).

v0.1.24

k6registry v0.1.24 is here 🎉!

This is an internal maintenance release.

Added testability of generated files

The generated registry and catalog will play an important role in the k6 binary provisioning subsystem, so it is important that there is no loss of service due to generated files. It is advisable to test the generated files to see if they meet the minimum requirements.

The --test flag can be used to test registry and catalog files generated with the --api flag. The test is successful if the file is not empty, contains k6 and at least one extension, and if all extensions meet the minimum requirements (e.g. it has versions).

v0.1.23

k6registry v0.1.23 is here 🎉!

This is an internal maintenance release.

Fix cache saving issue

The GitHub workflow is running with user id 1001 and group id 127. The k6registry docker container runs with the default user id in debian. As a consequence, the cache directory created under XDG_CACHE_HOME fails to save.

The solution is to use the same user id and group id as the GitHub workflow in the k6registry docker container (user id: 1001, group id: 127).