[alerts] adds support for index threshold index param string type

[pmuellr]

resolves #68575

Summary

The index threshold alert defines an index parameter which is typed as string | string[]. However the UI for this alert has been typing it as only string[].

This PR changes the UI to work with an incoming string value for this parameter. If the parameter is edited in the UI, it will always be set as an array, even if there is only one element.

Checklist

Delete any items that are not applicable to this PR.

• Unit or functional tests were updated or added to match the most common scenarios

[pmuellr]

@elasticmachine merge upstream

[elasticmachine]

Pinging @elastic/kibana-alerting-services (Team:Alerting Services)

[pmuellr]

Changing this test so that we have a jest test that will test a string index param (instead of the usual string[] type). It would be good to add a function test, I think, would need to create an alert using the API (passing a string typed index field), and then edit the alert and make sure the single index appears as expected in the UI. Do we have similar tests like this? Thoughts on where to add such a test?

[ymao1]

Could you use the esArchiver to load an archived alert with a string index param and then try to edit it in your functional test?

[pmuellr]

I think we should be able to create one via the API - I suspect that will be easier to figuring out esArchiver :-)

Let me see if I can add a quick one ...

[pmuellr]

I found one - I ended up changing the test in x-pack/test/functional_with_es_ssl/apps/triggers_actions_ui/details.ts, below, from using an array of indices to a single index string.

[gmmorris]

LGTM

It would be worth adding an e2e test for it, but not a blocker, as I know we'er trying to be more economical with UI tests :/

[pmuellr]

There is already an example of testing the array version of the index param in the alert_create_flyout tests, so it seemed like changing this other usage of the index threshold alert to use the string version would be appropriate.

[ymao1]

LGTM!

[pmuellr]

@elasticmachine merge upstream

[pmuellr]

Looks like a flaky test failure in the last build

A worker process has failed to exit gracefully and has been force exited. This is likely caused by tests leaking due to improper teardown. Try running with --detectOpenHandles to find leaks.
Summary of all failing tests
 FAIL  src/dev/build/lib/version_info.test.ts (24.116 s)
  ● isRelease = true › returns unchanged package.version, build sha, and build number

    thrown: "Exceeded timeout of 5000 ms for a test.
    Use jest.setTimeout(newTimeout) to increase the timeout value, if this is a long-running test."

      13 | 
      14 | describe('isRelease = true', () => {
    > 15 |   it('returns unchanged package.version, build sha, and build number', async () => {
         |   ^
      16 |     const versionInfo = await getVersionInfo({
      17 |       isRelease: true,
      18 |       pkg,

      at src/dev/build/lib/version_info.test.ts:15:3
      at Object.<anonymous> (src/dev/build/lib/version_info.test.ts:14:1)

so merging master again ...

[pmuellr]

@elasticmachine merge upstream

[kibanamachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: 0b718b5

Metrics [docs]

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id	before	after	diff
stackAlerts	114.5KB	114.6KB	+139.0B

History

• 💔 Build #100773 failed 080063a
• 💚 Build #100468 succeeded 9f95ce7
• 💚 Build #100029 succeeded 2fc19f1
• 💚 Build #99276 succeeded 2439918

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream