Use integration tests to generate coverage

[yurishkuro]

The plugin/storage/integration tests are using STORAGE env var to decide which tests to run. It makes sense for tests that require external storage, but badger/grpc-plugin are currently not running at all.

I propose the following changes:

• always run Badger tests
• always run grpc-plugin tests, but look for env variable pointing to the plugin binary path (to address [this comment](address https://github.com/jaegertracing/jaeger/pull/1461/files#r280031679))
• use -coverpkg directive to generate test coverage for the actual packages, and merge it with overall coverage (codecov.io allows submitting multiple reports from CI job)

[Beachyesh]

I see that this issue has been added as a good first issue, I'm new to contributing, how may I help? Please let me know, thanks!

[yurishkuro]

Help is appreciated. What kind of assistance are you looking for?

[yurishkuro]

Perhaps an even better way would be to change the tests from using integration build tag to have specific tag for each storage type, so that we don't even run irrelevant tests.

[rbroggi]

Dear @yurishkuro , I'm a first-timer here in Jaeger and as much as I work a bit with it and went through some documentation I'm not yet familiar with the code. This change sounds pretty straightforward. Some questions I had while trying to understand your suggested change:

1. Concerning your last comment around integration build tag - I see no build tag in any of the tests under the path plugin/storage/integration/. Are you suggesting to introduce different build tag for each of the tests under plugin/storage/integration/badgerstore_test.go and adapt the commands in the Makefile?

e.g.:

in plugin/storage/integration/badgerstore_test.go

// Copyright...
//go:build storage-integration-badge
// +build storage-integration-badge

...

and in Makefile

.PHONY: badger-storage-integration-test
badger-storage-integration-test:
		bash -c "set -e; set -o pipefail; $(GOTEST) -tags=storage-integration-badge $(STORAGE_PKGS) | $(COLORIZE)"

??

2. When you say that

badger/grpc-plugin are currently not running at all

you mean in the context of CI? github actions? In github actions I could see that there is a workflow (ci-memory-badger.yml) that runs the make target:

make mem-and-badger-storage-integration-test

.PHONY: mem-and-badger-storage-integration-test
mem-and-badger-storage-integration-test: badger-storage-integration-test grpc-plugin-storage-integration-test

.PHONY: badger-storage-integration-test
badger-storage-integration-test:
	STORAGE=badger $(MAKE) storage-integration-test

.PHONY: grpc-plugin-storage-integration-test
grpc-plugin-storage-integration-test:
	(cd examples/memstore-plugin/ && go build .)
	STORAGE=grpc-plugin $(MAKE) storage-integration-test

I was willing to contribute to Jaeger in the scope of the hacktoberfest and beyond, maybe we are too close to meet the deadline for hacktober fast but I'm willing to help the project anyways :)

[rbroggi]

OK I just realize that you addressed many of the issues in the PR2474.

Is there something else to be done? maybe the -coverpkg?

I see you are using go tool cover in the Makefile to handle the coverability. I guess we need to update the part of CONTRIBUTING.md mentioning ./scripts/cover.sh file (which does no longer exist).

[yurishkuro]

@rbroggi Yes your understanding about the build tags proposal is accurate. Right now we don't use build tags and instead control storage integrations via ENV var, which is weird since the all run all the time.

My PR #2474 didn't fix it, just added the other tests (which are fairly light weight) to also run all the time, to at least have them always executed one way or another.

[rbroggi]

Dear @yurishkuro , I will try to work on that tomorrow (I'm currently based in France so time to go to bed :) ). Thank you for the update and clarifications