Add components YAML file with Core and Extended info

[theletterf]

This adds a manual components.yaml file to map the support status of each EDOT Collector components: Core or Extended. This is necessary to properly render the automated table in the docs: https://www.elastic.co/docs/reference/opentelemetry/edot-collector/components

See: https://www.elastic.co/docs/reference/opentelemetry/compatibility/nomenclature#core-components

More context:

The intent here is that this list ONLY contains OTel components that we explicitly categorized as core (i.e. with full support etc.). All other OTel components must not be in this file and are then assumed to be extended.

Promoting a component to core MUST be a very explicit decision that requires PM involvement. So, the process of this promotion step basically will be by updating this file.

Any other components that we add to EDOT (as extended components won't and shouldn't be added automatically to this file).

So, if we have a test that ensures that all components listed in this file are actually dependencies, I don't see a big risk of this file to get out of sync.

[mergify]

This pull request does not have a backport label. Could you fix it @theletterf? 🙏
To fixup this pull request, you need to add the backport labels for the needed
branches, such as:

• backport-./d./d is the label that automatically backports to the 8./d branch. /d is the digit
• backport-active-all is the label that automatically backports to all active branches.
• backport-active-8 is the label that automatically backports to all active minor branches for the 8 major.
• backport-active-9 is the label that automatically backports to all active minor branches for the 9 major.

[swiatekm]

It'd be best if we could add a test that verifies all the components we ship in EDOT are present in this file. That doesn't need to happen in this PR if you're not up to it @theletterf, but then we should file a follow-up issue.

[theletterf]

@swiatekm @AlexanderWert I've created a simple test that uses the same strategy and the current docs automation, that is, reading go.mod. Probably not as elegant as using Factories, but it works.

[elasticmachine]

Pinging @elastic/elastic-agent-control-plane (Team:Elastic-Agent-Control-Plane)

[pchila]

Just a couple of suggestions for asserting the absence of errors (non-blocking)
As a more general question: @swiatekm was talking about a test that would ensure that all the components we ship in EDOT would appear in the file, while the test checks that go.mod contains the component listed in the file (the inclusion is reversed). Which condition we want to maintain here ?

[theletterf]

@pchila See #8530 (comment) for the rationale on why we're testing things this way.

[theletterf]

@pchila Fine if we skip CI / tests for this one?

[pchila]

@pchila Fine if we skip CI / tests for this one?

I am afraid we have to wait for the CI to finish after the last merge 😓

[elasticmachine]

💚 Build Succeeded

• Buildkite Build
• Commit: 5f9914a

History

• 💔 Build #22599 failed 3e6c73e
• 💛 Build #22584 was flaky b6d4b28
• 💔 Build #22580 failed 0c3d599
• 💛 Build #22532 was flaky ae0efbe

cc @theletterf

[elastic-sonarqube]

Quality Gate passed

Issues
0 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarQube