v0.1.36

k6registry v0.1.36 is here 🎉!

This is an internal maintenance release.

• Based on the properties of the registered extensions, metrics added and available as /metrics.json API endpoint.

v0.1.35

k6registry v0.1.35 is here 🎉!

This is an internal maintenance release.

• Using the latest go base image (golang:1.23.3-alpine3.20) in GitHub action image
• Update k6lint to v0.3.1
  • CODEOWNERS checker
  • TypeScript API declaration file checker (index.d.ts)

v0.1.34

k6registry v0.1.34 is here 🎉!

This is an internal maintenance release.

• Add go tooling to docker image (k6lint build checker requires it)
• Keep a list of failed k6lint checkers (for debugging purposes)
• Generate a grade badge that only contains the grade letter

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.