expand usage of e2e tests and scraperint (or similar)

[hughesjj]

Component(s)

scraperinttest and/or build constraints and/or makefile

Is your feature request related to a problem? Please describe.

Two issues I've faced writing integration tests inspired this issue. scraperinttest is amazing and I love it, but as far as I can tell it only supports

1. receiver configuration and
2. a single instance of a receiver at that

When I write examples or DIY my testing, I usually write things with docker compose and a full otel pipeline. This makes it easy to ex use filterprocessor and a logging exporter for zeroing in on the exact functionality I use, or even doing things such as having multiple receivers for every node in a (redis, but really any) cluster.

Describe the solution you'd like

I'd like to be able to run e2e tests against an entire otel pipeline, and not just my component.
At minimum, I'd like to be able to configure multiple receivers (of the same type) in scraperinttest

That said, I see a risk in increasing the complexity or runtime with going this route. Having a "full pipeline" easily accessible for testing is heavier than making it "tighter" to the given components.

Describe alternatives you've considered

• We could also add guidance on using "raw" test containers with a build target dependent on make docker-otelcontribcol or similar
• We could introduce a new build-constraint and/or make target
• We could expand the internal integration test primitives in scraperinttest to accomplish the minimal quality of life asks I have here

Additional context

scraperinttest Run function

[crobert-1]

Sounds like a good idea to me, test enhancements are always welcome! If you don't get much input here feel free to submit a PR and discussion can happen there as well.

Is there a way to build on top of existing functionality within scraperinttest so that the existing tests stay with their smaller scope, and then new test features (like a full pipeline) just call those existing functions? I'm wondering if this would minimize the complexity and runtime concerns.

[hughesjj]

We've been seeing more flaky tests, I think adding a new target for 'cluster' or similar would help things like flink, kafka, redis, even k8s might be useful.

We might want to use native docker/docker-compose instead of test containers instead of wrapping though testcontainers via scraperinttest, but that's a can of worms

[github-actions]

This issue has been inactive for 60 days. It will be closed in 60 days if there is no activity. To ping code owners by adding a component label, see Adding Labels via Comments, or if you are unsure of which component this issue relates to, please ping @open-telemetry/collector-contrib-triagers. If this issue is still relevant, please ping the code owners or leave a comment explaining why it is still relevant. Otherwise, please close it.

[github-actions]

This issue has been inactive for 60 days. It will be closed in 60 days if there is no activity. To ping code owners by adding a component label, see Adding Labels via Comments, or if you are unsure of which component this issue relates to, please ping @open-telemetry/collector-contrib-triagers. If this issue is still relevant, please ping the code owners or leave a comment explaining why it is still relevant. Otherwise, please close it.

[github-actions]

This issue has been closed as inactive because it has been stale for 120 days with no activity.