Notify the response ops team whenever a change is made to various task runtime parameters

[mikecote]

Description

To increase our confidence when doing rollbacks on serverless, we should implement a PR review process to ensure the schema changes that are made in specific areas are done in a backwards / rollback compatible manner. Without this assurance, we risk performing rollbacks with tasks running incorrectly or unsuccessfully.

To accomplish this, we should follow similar patterns as done for notifying of new task types [0] by creating an integration test that would require changes within a response ops CODEOWNER file to pass. This change would create a review ping to the team whenever a schema change is made to the following areas:

• Task parameters
• Rule type parameters
• Connector type config, secrets or parameters

Note that compared to the reference pattern, we need to go into detail in the schema to ensure an addition / change / removal of a field triggers a ping. To accomplish this, we may need to explore the getSchemaStructure API on the config-schema objects.

To facilitate reviewing these types of changes, we should clearly indicate to the developer that they should explain in the PR description how the change affects rollbacks and ZDT. We should also explain for the response ops PR reviewer what they need to assess when pinged.

Definition of Done

• Response ops team is required for a PR review when a task type changes their parameters schema
• Response ops team is required for a PR review when a rule type changes their rule parameters schema
• Response ops team is required for a PR review when a connector type changes their config, secrets or parameters schema

[0] https://github.com/elastic/kibana/blob/6bfdde6cfcdb1ec876f0177572bfbe28abb8fd2f/x-pack/test/plugin_api_integration/test_suites/task_manager/check_registered_task_types.ts

[elasticmachine]

Pinging @elastic/response-ops (Team:ResponseOps)

[mikecote]

I'm going to close this issue. We have in place the notifications for rule params and in progress the connector config, secrets and params (#175018). It's not worth exploring the task params at this time because we get notified when a new task type is registered already and the params probably don't change often enough to be concerned in the first iteration.