Test-wide Tags: CLI tags overwrites code tags

[chaosbox]

Brief summary

Our current setup uses the "k6-operator" for test orchestration, recent upgrade brought in a change that adds a couple of additional tags which are passed to the runner. As a result, the code level tags are being ignored, we noticed that there is a test that covers this specific use-case. We would like to understand if this is by design? it wasnt very clear from the documentation if its mutually exclusive.

Considering the current tag implementation which is a map, it will be useful to be able to merge the tags from multiple layers. If you think its useful, we can open a PR and push the small change, otherwise we need to open a PR in the operator or refactor our scripts to pass test-wide tags as a CLI args. If we have custom code to determine tag values, it might be useful to have the merge operation especially if we are going the operator route.

Operator adds default instance_id and job_name tags here

k6 version

0.43.1

OS

linux

Docker version and image (if applicable)

No response

Steps to reproduce the problem

Script: Global options contains the "testScenario" tag

import http from 'k6/http';

export default function () {
	http.get('https://test-api.k6.io/');
};

export const options = {
	discardResponseBodies: true,
	tags: {
		testScenario: "peak-load",
	}
};

Expected behaviour

k6 run -d 10s -i 2 ./example.js --out csv --tag cliTag=test

Output:
http_req_receiving,1682596478,0.155000,,,,true,,GET,https://test-api.k6.io/,HTTP/1.1,default,,200,,tls1.3,https://test-api.k6.io/,cliTag=test,testScenario=peak-load,

Actual behaviour

Output:
http_req_receiving,1682596478,0.155000,,,,true,,GET,https://test-api.k6.io/,HTTP/1.1,default,,200,,tls1.3,https://test-api.k6.io/,cliTag=test,

[mstoykov]

Hi @chaosbox, thanks for reporting this.

This was previously discussed in grafana/k6#2694.

As discussed there the problem is that all options basically get overridden from one layer to the next as you have observed.

The thing is that this is the most consistent and obvious way to do it as otherwise:

1. most options cant' be merged or will be really hard to define what merging them is. scenarios is the prime example.
2. it will be really strange if some options are "merged" and some aren't
3. how do youremove a tag defined in the script? Do we now have additional cli flags for all of this.

There is also a workaround which likely will work for your case.

But I feel like this should be ... fixed in some way. The easiest of which is for the k6-operator to read the tags from the script and set them on the cli.

To this end I will move this to the k6-operator repo as we already have an issue here discussing the problem.

You are of course welcome to propose other solutions if you think something else will be viable.

[yorugac]

Hi @chaosbox, sorry for the delay. Thanks for opening the issue. Did the workaround work for you?

TBH, I'm not fond of the idea of the operator becoming a "scrapyard" of the k6 workarounds 😅 @mstoykov I think this request (meaning merging of tags only, not any other option) is a valid request even outside of k6-operator's context: is there any chance for this being addressed in croconf work? The k6 issue #883 is also mentioned in Ned's comment here... It sounds to me like the approach to options in k6 would be re-worked in croconf.

[chaosbox]

hi @yorugac, thankyou, worked around by treating test-wide tags as mutually exclusive and set only through CLI, operator now just appends the additional tags.