Add github action for jaeger integration tests

[Ashmita152]

Signed-off-by: Ashmita Bohara [email protected]

Which problem is this PR solving?

This PR adds GitHub actions for running integration tests for Elasticsearch, Cassandra, Memory, Kafka & Badger.

Part of #2645.

Short description of the changes

Also it removes --interactive and --tty flags from test-compile-es-scripts makefile directive, which shouldn't be used there and was causing elasticsearch integration test to fail on GH actions with this error (not sure how it is working on travis, maybe different docker version)

docker run --rm -it -v /home/runner/work/jaeger/jaeger:/tmp/jaeger python:3-alpine /usr/local/bin/python -m py_compile /tmp/jaeger/plugin/storage/es/esRollover.py
the input device is not a TTY

[yurishkuro]

I think it might be better to define all our CI jobs in a single file. That way we'll have better control over their orchestration, like using .needs to establish dependencies, define common parameters via env, like the Go version.

[Ashmita152]

Sure @yurishkuro that makes sense.

[jpkrohling]

The down side is that we can only trigger new runs on a per-workflow basis, meaning that all jobs within the workflow will be restarted.

[yurishkuro]

yeah, if we cannot rerun individual jobs then it's better to have them as separate workflows.

It's annoying that we'd have to repeat a lot of boilerplate. At some point we might want to consider auto-generating the YAML files from smaller pieces. I originally was looking at this approach of using YAML aliases, but that only works in a single file.

[jpkrohling]

I think we can indeed have multiple workflows in the same file, but it would be a huge YAML no matter how much we Don't-Repeat-Ourselves. Let's see what's the final result, and we can then iterate and refactor.

[Ashmita152]

Thank you for the review. I am little confused if I should merge unit test and integration tests into one yaml. Using matrix, definitely made the config much cleaner.

[Ashmita152]

Also, I think our badger integration tests broke due to some recent commit.

[codecov]

Codecov Report

Merging #2649 (b021c83) into master (24fb6bc) will increase coverage by 0.01%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #2649      +/-   ##
==========================================
+ Coverage   95.10%   95.11%   +0.01%     
==========================================
  Files         213      213              
  Lines        9491     9491              
==========================================
+ Hits         9026     9027       +1     
+ Misses        388      387       -1     
  Partials       77       77              

Impacted Files	Coverage Δ
cmd/query/app/static_handler.go	83.03% <0.00%> (-1.79%)	⬇️
plugin/storage/integration/integration.go	77.90% <0.00%> (+0.55%)	⬆️
cmd/query/app/server.go	90.16% <0.00%> (+1.63%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 24fb6bc...b021c83. Read the comment docs.

[yurishkuro]

I am little confused if I should merge unit test and integration tests into one yaml. Using matrix, definitely made the config much cleaner.

@Ashmita152 we need to be able to restart individual jobs, not the complete CI run. If we can do it with a single workflow file then I would consolidate all CI into one place (just like it was with .travis.yml), otherwise it's better to have independent workflow files.

[Ashmita152]

@yurishkuro Looking at the GitHub community threads, it seems like GH actions don't have support restarting individual job. I would suggest maybe we can go ahead with different workflows for now and merge them into one once GitHub actions support it.

[yurishkuro]

Let's go with different files. My only other alternative suggestion is to write a shell script that would generate the Yaml files, and execute it as a commit hook. Since the files are only going to be different in one command, the script could be fairly straightforward.

[Ashmita152]

Hi @yurishkuro

It makes sense to have a script generate the workflow files. Let me look at that option.

[Ashmita152]

Hi @yurishkuro

I thought maybe I can do the script version in another PR since I am not quite familiar with git hooks. To have the CI working quickly, we moved each integration test into separate files. Let me know what you think. Thanks.

[yurishkuro]

yes, let's start with explicit files, auto-generation can be done later

[Ashmita152]

Thank you @yurishkuro updated the PR with the feedback changes.

[yurishkuro]

Thanks!