k6 icon indicating copy to clipboard operation
k6 copied to clipboard

Migrate k6 cloud command and subcommands to cloud API v6

Open oleiade opened this issue 7 months ago • 1 comments

The Grafana k6 cloud team recently published a new version of our REST API, v6.

Currently, k6 still uses the older API version to interact with the cloud through the k6 cloud subcommands. We should refactor those in order to migrate to the newer API version.

This has been requested as a priority for k6 v2.0.0.

oleiade avatar Aug 05 '25 09:08 oleiade

Maintainers and stakeholders for this migration met today and discussed the scope of this issue, decisions, and next steps, in order to enable us to implement this change.

Scope

In Scope:

Similar to what we currently achieve with the v1 API, we intend to maintain the following functionalities when transitioning to the v6 API:

  • Authentication.
  • Uploading an archive.
  • Test lifecycle management: Starting, aborting, and retrieving test progress.

Out of Scope (for now):

  • Data Ingestion: Ingestion of logs, traces, and metrics is out of scope for this specific migration.

Note: Eventually, ingestion URLs will most likely be handled dynamically.

Constraints

Stack ID

The whole v6 API relies on the "Stack ID" in order to provide access to its resources, which is currently not available to k6. A PR is in progress to modify the k6 cloud login operation in a way that obtains a stack ID that will make the transition to the v6 API possible.

Because the v6 API relies heavily on the Stack ID, which requires users to utilize the new cloud login behavior, we cannot simply drop v1 immediately. We must maintain v1 and v6 side-by-side until the new login behavior becomes the de facto standard (likely until k6 v3.0.0 is released, and k6 v1.0.0 is deprecated).

Public API & Backward Compatibility

The Go cloudapi package is public. While the underlying implementation migrates to v6, the public Go API surface should remain stable to avoid breaking changes for integrators.

We should aim to prioritize the ease of use for our end-users. Dropping the v1 API support is acceptable in the future only if we ensure strict User Experience (UX) parity, and ensure any transition (such as logging in again using k6 cloud login to obtain a stack ID) is smooth, documented, and seamless from the user perspective.

oleiade avatar Nov 18 '25 14:11 oleiade