For a more complete overview, see "Project Structure" in contributing.md.
There are two supported patterns for Plugin Framework data sources. Choose the one that fits the entity's Read complexity.
Use [entitycore.NewKibanaDataSource] or [entitycore.NewElasticsearchDataSource] when the data source follows the standard read pipeline without conditional early returns or complex state manipulation:
- Decode config
- Resolve scoped client
- Call API
- Map response to model
- Set state
The envelope owns steps 1, 2, and 5. The concrete package provides only a schema factory (without connection blocks), a model embedding [entitycore.KibanaConnectionField] or [entitycore.ElasticsearchConnectionField], and a pure read function.
Good fits: single-entity lookups (e.g., Agent Builder workflow, Agent Builder tool, spaces list).
Embed [*entitycore.DataSourceBase] and implement [datasource.DataSource] directly when the Read method needs:
- Conditional early returns or branching API calls
- Custom state manipulation beyond simple model mapping
- Multiple API calls with interdependent logic (e.g., tool dependency graphs)
- Special diagnostic handling that doesn't fit the uniform pipeline
Good fits: Agent Builder agent (tool dependency graph, version-gated workflow embedding), multi-step lookups.
internal/: provider implementation (Go)internal/elasticsearch/: Elasticsearch-specific resources and logicinternal/kibana/: Kibana-specific resources and logicinternal/fleet/: Fleet-specific resources and logic
provider/: provider wiring and configurationgenerated/: generated API clients (notablygenerated/kbapi)docs/: generated provider docstemplates/: docs templatesexamples/: examples used by docs generation and as referencesscripts/: dev/CI helper scripts