Verify number of traces in verify-traces steps

[andreasgerstmayr]

• speed up telemetrygen by generating 10 traces instead of running for 30 seconds
• use Tempo API where applicable
• install minio storage before each test which writes or reads from storage (to get deterministic results)

Resolves: #98
Resolves: #490

[andreasgerstmayr]

Unfortunately the diff is a mess because it doesn't detect the renames properly (I had to increment the test step numbers to add a new 00-install-storage.yaml step at the beginning of each smoketest).

[codecov-commenter]

Codecov Report

Merging #509 (052c068) into main (b4fdf61) will increase coverage by 0.08%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main     #509      +/-   ##
==========================================
+ Coverage   78.66%   78.74%   +0.08%     
==========================================
  Files          60       60              
  Lines        4513     4531      +18     
==========================================
+ Hits         3550     3568      +18     
  Misses        809      809              
  Partials      154      154              

Flag	Coverage Δ
unittests	78.74% <100.00%> (+0.08%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files Changed	Coverage Δ
apis/tempo/v1alpha1/tempostack_webhook.go	81.07% <100.00%> (+0.36%)	⬆️

... and 2 files with indirect coverage changes

[iblancasa]

Maybe, it would make sense to move the "verification of traces" logic to one script and mount it in a volume or something. Or to build our own image to run the tests. Just as a way to make it easier to read the tests files and avoid copying/pasting if we need to modify something.

Also... would it make sense to pin the registry.gitlab.com/gitlab-ci-utils/curl-jq image to an specific version? I suppose there should not be problems and should be something easy to fix just in case.

[andreasgerstmayr]

Maybe, it would make sense to move the "verification of traces" logic to one script and mount it in a volume or something. Or to build our own image to run the tests. Just as a way to make it easier to read the tests files and avoid copying/pasting if we need to modify something.

The scripts are not identical, some query the Tempo API, some the Jaeger API, some use mTLS, some use a different (static) namespace. We could create a parameterized script with all the different use cases, but I'm not sure if it's worth it.

Also... would it make sense to pin the registry.gitlab.com/gitlab-ci-utils/curl-jq image to an specific version? I suppose there should not be problems and should be something easy to fix just in case.

+1, done

[pavolloffay]

@andreasgerstmayr did you run the tests on OCP?

[andreasgerstmayr]

@andreasgerstmayr did you run the tests on OCP?

Yes