Fixed alerting_api_integration/security_and_spaces tests failing if actions proxy set on for parallel process running using commands 'scripts/functional_tests_server' and 'scripts/functional_test_runner'

[YulNaumenko]

Added new environment variable ALERTING_PROXY_PORT with value "61${parallelId}5"
Tested locally by using commands 'scripts/functional_tests_server' and 'scripts/functional_test_runner'
Resolve #75386, #75522, #75722

[elasticmachine]

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

[gmmorris]

LGTM and works as expected 👍

I would love it if we could use a command line arg instead of commented out config, but it isn't a blocker :D

[pmuellr]

I'm a little concerned because if I run FTS / FTR without a const proxy port set in the config, all the tests pass for actions - both security and spaces, and spaces only. But I see a lot of warnings and errors in the FTS terminal showing http-related errors running actions.

Is the intention that if you want to run FTS / FTR locally you have to set the proxy port? If so, then we at least need an env var to set it, but then we might as well also have some port that we default to as well.

Another idea - FTS has to be running before you start FTR, so we could add a route to FTS that returned the proxy port, or the whole proxy url, which FTR could call to get it. Could be a lot of work tho.

[YulNaumenko]

I'm a little concerned because if I run FTS / FTR without a const proxy port set in the config, all the tests pass for actions - both security and spaces, and spaces only. But I see a lot of warnings and errors in the FTS terminal showing http-related errors running actions.

Is the intention that if you want to run FTS / FTR locally you have to set the proxy port? If so, then we at least need an env var to set it, but then we might as well also have some port that we default to as well.

Another idea - FTS has to be running before you start FTR, so we could add a route to FTS that returned the proxy port, or the whole proxy url, which FTR could call to get it. Could be a lot of work tho.

@pmuellr you have a good catch here about the warnings in the FTS terminal - I realized that I added the fix with random proxy port but didn't do this for Webhook and Slack simulator servers. Why the tests are green I'm surprised - ops :)

[pmuellr]

I noticed that we're doing a logger.info() in the slack webhook when the proxy is used:

kibana/x-pack/plugins/actions/server/builtin_action_types/slack.ts

Lines 120 to 123 in 9111d50

	if (execOptions.proxySettings) {
	proxyAgent = getProxyAgent(execOptions.proxySettings, logger);
	logger.info(`IncomingWebhook was called with proxyUrl ${execOptions.proxySettings.proxyUrl}`);
	}

and that we have a test that the logger.info() is run:

kibana/x-pack/plugins/actions/server/builtin_action_types/slack.test.ts

Lines 212 to 214 in 9111d50

	expect(mockedLogger.info).toHaveBeenCalledWith(
	'IncomingWebhook was called with proxyUrl https://someproxyhost'
	);

Seems like this should be changed to a logger.debug().

[pmuellr]

LGTM; I noticed a logger.info() from the prior PR that seems like it should be changed to a debug(), noted in a separate comment.

[spalger]

Operations: Pipeline changes LGTM

[kibanamachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: 9e4e5d7

Build metrics

✅ unchanged

History

• 💔 Build #70123 failed afd4809
• 💔 Build #69901 failed 0e713b3
• 💔 Build #69899 failed 7aef590
• 💛 Build #69891 was flaky bad2d49
• 💚 Build #69870 succeeded 06fbc740692698815a0be2a468450e7823daa9d3

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