How to properly test a change E2E in beats that is also affecting the behaviour of integrations package?
Scenario where things get tricky without knowing this:
A PR is adding a new option for the azure config.
Testing this config option would require releasing a new version of beats and then spinning up the stack locally to check the functionality (via elastic-package stack up -v -d).
After testing, an enhancement in usability is discovered or the config option is bugged. Any change would require waiting for another release cycle to be available.
This is worrying, as without proper testing, bugged/unpolished features can be shipped unknowingly.
How to properly test a change E2E in beats that is also affecting the behaviour of integrations package?
Scenario where things get tricky without knowing this:
elastic-package stack up -v -d
).This is worrying, as without proper testing, bugged/unpolished features can be shipped unknowingly.