[Ingest Manager] Creating test packages and where to store them

[neptunian]

Once we have the ability to run the registry locally, we need packages that are defined for the purpose of testing all the various cases which don't always exist in "real" packages.

• Where should we store these packages? In Kibana or in the registry?
• How should we go about creating them? Perhaps a modified System package? Ideally we can also use these for functional or e2e tests, for example updating a package while the agent is running and sending data

[elasticmachine]

Pinging @elastic/ingest-management (Team:Ingest Management)

[ruflin]

We should store these packages in Kibana. This should make the tests reproducible. Each Kibana commit will be attached to a specific set of packages and a specific commit of the registry.

The system package is rather complex. I would create packages as minimal as possible that cover our test case. This will make it easier to maintain.

@neptunian It would be great to have a list of all the test cases you want to cover so we can start crafting the packages accordingly.

[neptunian]

These are some of the tests I think are relevant to crafting the packages.

• testing the package installs all assets correctly, every type of asset to install should exist
• in an update, the old assets that don’t exist in the upgrade version were deleted (eg: the upgrade package has removed a visualization)
• in an update, templates have field mappings with different data types (current index must be rolled over).
• Fails when trying to install/update to an outdated version

[neptunian]

@ruflin if the packages live in Kibana, that means we can point the locally running registry to serve those packages?

[ruflin]

By local I assume you mean the one running as part of the KB tests? Then yes.

[skh]

Closing this as we now have test packages in the api integration test fixtures. Please reopen if more needs to be done that I'm not aware of.