The current state of the Fleet and Beats projects is not represented with the current suite layout. We have fleet, helm and k8s-autodiscover test suites, which can be triggered in isolation, even filtering by cucumber tags. But after having the elastic-agent extracted to a separate repo, then the execution of the suites should be changed in consequence, as it's no longer maintainable without effort: what changes trigger what suite.

This is an initial (and rudimentary) proposal:

1. the elastic-agent repo should trigger the fleet test suite, plus k8s-autodiscover suite for the elastic-agent

   • already covered in Include k8s-autodiscover for elastic-agent test suite in fleet nightly build #2140
   • there are scenarios that download binaries for metricbeat/filebeat (running the agent on top of them). We should verify if we need to run the e2e tests after changes on those beat dependencies. I suggest opening a discussion as it's not that trivial without rebuilding all projects each time.

2. the beats repo should trigger the helm charts test suite, plus k8s-autodiscover suite for not the elastic-agent. I wonder if there should be a case where a change on beats' k8s-autodiscover code should trigger all scenarios for k8s-autodiscover on the e2e. But again, because the elastic-agent project live in another repository, it's not that easy to correlate a commit on beats repo (where the core of the k8s-autodiscover feature lives) with a commit on the elastic-agent repo.

   • we could improve the way to filter the CI execution, which currently support selecting a comma-separated list of suites, adding the ability to include/exclude tags using Cucumber boolean operators for tags.

@jlind23 @ruflin @ph @cmacknz @adam-stokes @elastic/observablt-robots, thoughts?