# Backport
This will backport the following commits from `main` to `8.7`:
- [[functional tests] split fleet_api_integration config into smaller
ones (#156407)](https://github.com/elastic/kibana/pull/156407)
<!--- Backport version: 8.9.7 -->
### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sqren/backport)
<!--BACKPORT [{"author":{"name":"Dzmitry
Lemechko","email":"dzmitry.lemechko@elastic.co"},"sourceCommit":{"committedDate":"2023-05-03T14:26:58Z","message":"[functional
tests] split fleet_api_integration config into smaller ones
(#156407)\n\n## Summary\r\n\r\nRuntime for
`fleet_api_integration/config` crossed the 38 min limit.\r\nIdeally
config runtime should be <10 min so that pipeline can quickly\r\nretry
failed configs (we do 1 retry on CI)\r\n\r\n<img width=\"1600\"
alt=\"image\"\r\nsrc=\"https://user-images.githubusercontent.com/10977896/235707744-3120e1e9-4882-493f-9ee0-86016a765401.png\">\r\n\r\n\r\nThis
PR splits the existing config into few smaller
ones:\r\n\r\n```\r\nx-pack/test/fleet_api_integration/config.agent.ts
15m 15s\r\nx-pack/test/fleet_api_integration/config.agent_policy.ts 4m
10s\r\nx-pack/test/fleet_api_integration/config.epm.ts 8m
12s\r\nx-pack/test/fleet_api_integration/config.package_policy.ts 10m
54s\r\n// combines multiple test
files\r\nx-pack/test/fleet_api_integration/config.fleet.ts 5m
2s\r\n```","sha":"1c777a2e702f7c5ae9c1b86063515c0a27368efb","branchLabelMapping":{"^v8.9.0$":"main","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:skip","Team:Fleet","v8.8.0","v8.7.2","v8.9.0"],"number":156407,"url":"https://github.com/elastic/kibana/pull/156407","mergeCommit":{"message":"[functional
tests] split fleet_api_integration config into smaller ones
(#156407)\n\n## Summary\r\n\r\nRuntime for
`fleet_api_integration/config` crossed the 38 min limit.\r\nIdeally
config runtime should be <10 min so that pipeline can quickly\r\nretry
failed configs (we do 1 retry on CI)\r\n\r\n<img width=\"1600\"
alt=\"image\"\r\nsrc=\"https://user-images.githubusercontent.com/10977896/235707744-3120e1e9-4882-493f-9ee0-86016a765401.png\">\r\n\r\n\r\nThis
PR splits the existing config into few smaller
ones:\r\n\r\n```\r\nx-pack/test/fleet_api_integration/config.agent.ts
15m 15s\r\nx-pack/test/fleet_api_integration/config.agent_policy.ts 4m
10s\r\nx-pack/test/fleet_api_integration/config.epm.ts 8m
12s\r\nx-pack/test/fleet_api_integration/config.package_policy.ts 10m
54s\r\n// combines multiple test
files\r\nx-pack/test/fleet_api_integration/config.fleet.ts 5m
2s\r\n```","sha":"1c777a2e702f7c5ae9c1b86063515c0a27368efb"}},"sourceBranch":"main","suggestedTargetBranches":["8.7"],"targetPullRequestStates":[{"branch":"8.8","label":"v8.8.0","labelRegex":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"url":"https://github.com/elastic/kibana/pull/156559","number":156559,"state":"MERGED","mergeCommit":{"sha":"d61043fdfa0b07f5156a1f78d42b6640e90edd1c","message":"[8.8]
[functional tests] split fleet_api_integration config into smaller ones
(#156407) (#156559)\n\n# Backport\n\nThis will backport the following
commits from `main` to `8.8`:\n- [[functional tests] split
fleet_api_integration config into smaller\nones
(#156407)](https://github.com/elastic/kibana/pull/156407)\n\n<!---
Backport version: 8.9.7 -->\n\n### Questions ?\nPlease refer to the
[Backport
tool\ndocumentation](https://github.com/sqren/backport)\n\n<!--BACKPORT
[{\"author\":{\"name\":\"Dzmitry\nLemechko\",\"email\":\"dzmitry.lemechko@elastic.co\"},\"sourceCommit\":{\"committedDate\":\"2023-05-03T14:26:58Z\",\"message\":\"[functional\ntests]
split fleet_api_integration config into smaller ones\n(#156407)\\n\\n##
Summary\\r\\n\\r\\nRuntime for\n`fleet_api_integration/config` crossed
the 38 min limit.\\r\\nIdeally\nconfig runtime should be <10 min so that
pipeline can quickly\\r\\nretry\nfailed configs (we do 1 retry on
CI)\\r\\n\\r\\n<img
width=\\\"1600\\\"\nalt=\\\"image\\\"\\r\\nsrc=\\\"https://user-images.githubusercontent.com/10977896/235707744-3120e1e9-4882-493f-9ee0-86016a765401.png\\\">\\r\\n\\r\\n\\r\\nThis\nPR
splits the existing config into few
smaller\nones:\\r\\n\\r\\n```\\r\\nx-pack/test/fleet_api_integration/config.agent.ts\n15m
15s\\r\\nx-pack/test/fleet_api_integration/config.agent_policy.ts
4m\n10s\\r\\nx-pack/test/fleet_api_integration/config.epm.ts
8m\n12s\\r\\nx-pack/test/fleet_api_integration/config.package_policy.ts
10m\n54s\\r\\n// combines multiple
test\nfiles\\r\\nx-pack/test/fleet_api_integration/config.fleet.ts
5m\n2s\\r\\n```\",\"sha\":\"1c777a2e702f7c5ae9c1b86063515c0a27368efb\",\"branchLabelMapping\":{\"^v8.9.0$\":\"main\",\"^v(\\\\d+).(\\\\d+).\\\\d+$\":\"$1.$2\"}},\"sourcePullRequest\":{\"labels\":[\"release_note:skip\",\"Team:Fleet\",\"v8.8.0\",\"v8.7.2\",\"v8.9.0\"],\"number\":156407,\"url\":\"https://github.com/elastic/kibana/pull/156407\",\"mergeCommit\":{\"message\":\"[functional\ntests]
split fleet_api_integration config into smaller ones\n(#156407)\\n\\n##
Summary\\r\\n\\r\\nRuntime for\n`fleet_api_integration/config` crossed
the 38 min limit.\\r\\nIdeally\nconfig runtime should be <10 min so that
pipeline can quickly\\r\\nretry\nfailed configs (we do 1 retry on
CI)\\r\\n\\r\\n<img
width=\\\"1600\\\"\nalt=\\\"image\\\"\\r\\nsrc=\\\"https://user-images.githubusercontent.com/10977896/235707744-3120e1e9-4882-493f-9ee0-86016a765401.png\\\">\\r\\n\\r\\n\\r\\nThis\nPR
splits the existing config into few
smaller\nones:\\r\\n\\r\\n```\\r\\nx-pack/test/fleet_api_integration/config.agent.ts\n15m
15s\\r\\nx-pack/test/fleet_api_integration/config.agent_policy.ts
4m\n10s\\r\\nx-pack/test/fleet_api_integration/config.epm.ts
8m\n12s\\r\\nx-pack/test/fleet_api_integration/config.package_policy.ts
10m\n54s\\r\\n// combines multiple
test\nfiles\\r\\nx-pack/test/fleet_api_integration/config.fleet.ts
5m\n2s\\r\\n```\",\"sha\":\"1c777a2e702f7c5ae9c1b86063515c0a27368efb\"}},\"sourceBranch\":\"main\",\"suggestedTargetBranches\":[\"8.8\",\"8.7\"],\"targetPullRequestStates\":[{\"branch\":\"8.8\",\"label\":\"v8.8.0\",\"labelRegex\":\"^v(\\\\d+).(\\\\d+).\\\\d+$\",\"isSourceBranch\":false,\"state\":\"NOT_CREATED\"},{\"branch\":\"8.7\",\"label\":\"v8.7.2\",\"labelRegex\":\"^v(\\\\d+).(\\\\d+).\\\\d+$\",\"isSourceBranch\":false,\"state\":\"NOT_CREATED\"},{\"branch\":\"main\",\"label\":\"v8.9.0\",\"labelRegex\":\"^v8.9.0$\",\"isSourceBranch\":true,\"state\":\"MERGED\",\"url\":\"https://github.com/elastic/kibana/pull/156407\",\"number\":156407,\"mergeCommit\":{\"message\":\"[functional\ntests]
split fleet_api_integration config into smaller ones\n(#156407)\\n\\n##
Summary\\r\\n\\r\\nRuntime for\n`fleet_api_integration/config` crossed
the 38 min limit.\\r\\nIdeally\nconfig runtime should be <10 min so that
pipeline can quickly\\r\\nretry\nfailed configs (we do 1 retry on
CI)\\r\\n\\r\\n<img
width=\\\"1600\\\"\nalt=\\\"image\\\"\\r\\nsrc=\\\"https://user-images.githubusercontent.com/10977896/235707744-3120e1e9-4882-493f-9ee0-86016a765401.png\\\">\\r\\n\\r\\n\\r\\nThis\nPR
splits the existing config into few
smaller\nones:\\r\\n\\r\\n```\\r\\nx-pack/test/fleet_api_integration/config.agent.ts\n15m
15s\\r\\nx-pack/test/fleet_api_integration/config.agent_policy.ts
4m\n10s\\r\\nx-pack/test/fleet_api_integration/config.epm.ts
8m\n12s\\r\\nx-pack/test/fleet_api_integration/config.package_policy.ts
10m\n54s\\r\\n// combines multiple
test\nfiles\\r\\nx-pack/test/fleet_api_integration/config.fleet.ts
5m\n2s\\r\\n```\",\"sha\":\"1c777a2e702f7c5ae9c1b86063515c0a27368efb\"}}]}]\nBACKPORT-->\n\nCo-authored-by:
Dzmitry Lemechko
<dzmitry.lemechko@elastic.co>"}},{"branch":"8.7","label":"v8.7.2","labelRegex":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"},{"branch":"main","label":"v8.9.0","labelRegex":"^v8.9.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/156407","number":156407,"mergeCommit":{"message":"[functional
tests] split fleet_api_integration config into smaller ones
(#156407)\n\n## Summary\r\n\r\nRuntime for
`fleet_api_integration/config` crossed the 38 min limit.\r\nIdeally
config runtime should be <10 min so that pipeline can quickly\r\nretry
failed configs (we do 1 retry on CI)\r\n\r\n<img width=\"1600\"
alt=\"image\"\r\nsrc=\"https://user-images.githubusercontent.com/10977896/235707744-3120e1e9-4882-493f-9ee0-86016a765401.png\">\r\n\r\n\r\nThis
PR splits the existing config into few smaller
ones:\r\n\r\n```\r\nx-pack/test/fleet_api_integration/config.agent.ts
15m 15s\r\nx-pack/test/fleet_api_integration/config.agent_policy.ts 4m
10s\r\nx-pack/test/fleet_api_integration/config.epm.ts 8m
12s\r\nx-pack/test/fleet_api_integration/config.package_policy.ts 10m
54s\r\n// combines multiple test
files\r\nx-pack/test/fleet_api_integration/config.fleet.ts 5m
2s\r\n```","sha":"1c777a2e702f7c5ae9c1b86063515c0a27368efb"}}]}]
BACKPORT-->
# Backport
This will backport the following commits from `main` to `8.7`:
- [[functional tests] split security and spaces ftr configs
(#156350)](https://github.com/elastic/kibana/pull/156350)
<!--- Backport version: 8.9.7 -->
### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sqren/backport)
<!--BACKPORT [{"author":{"name":"Dzmitry
Lemechko","email":"dzmitry.lemechko@elastic.co"},"sourceCommit":{"committedDate":"2023-05-03T06:57:57Z","message":"[functional
tests] split security and spaces ftr configs (#156350)\n\n##
Summary\r\n\r\nSplitting ftr configs to speed up ftr tests run on CI
\r\n\r\n```\r\nThe following \"Functional Tests\" configs have durations
that exceed the maximum amount of time desired for a single CI job.
\r\nThis is not an error, and if you don't own any of these configs then
you can ignore this warning.If you own any of these\r\nconfigs please
split them up ASAP and ask Operations if you have questions about how to
do
that.\r\n\r\nx-pack/test/spaces_api_integration/security_and_spaces/config_basic.ts:
38.2
minutes\r\nx-pack/test/spaces_api_integration/security_and_spaces/config_trial.ts:
38.2 minutes\r\n```\r\n\r\nAfter
split:\r\nx-pack/test/spaces_api_integration/security_and_spaces/config_basic.ts\r\n20m
29s\r\n\r\nx-pack/test/spaces_api_integration/security_and_spaces/copy_to_space_config_basic.ts\r\n20m
52s\r\nx-pack/test/spaces_api_integration/security_and_spaces/config_trial.ts\r\n19m
57s\r\n\r\nx-pack/test/spaces_api_integration/security_and_spaces/copy_to_space_config_trial.ts\r\n21m
5s\r\n\r\nRebalancing it with other configs should speedup CI by at
least
few\r\nminutes","sha":"424eae3f4d0f55f684a5b3c3b46847eb723233c9","branchLabelMapping":{"^v8.9.0$":"main","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:skip","v8.8.0","v8.7.2","v8.9.0"],"number":156350,"url":"https://github.com/elastic/kibana/pull/156350","mergeCommit":{"message":"[functional
tests] split security and spaces ftr configs (#156350)\n\n##
Summary\r\n\r\nSplitting ftr configs to speed up ftr tests run on CI
\r\n\r\n```\r\nThe following \"Functional Tests\" configs have durations
that exceed the maximum amount of time desired for a single CI job.
\r\nThis is not an error, and if you don't own any of these configs then
you can ignore this warning.If you own any of these\r\nconfigs please
split them up ASAP and ask Operations if you have questions about how to
do
that.\r\n\r\nx-pack/test/spaces_api_integration/security_and_spaces/config_basic.ts:
38.2
minutes\r\nx-pack/test/spaces_api_integration/security_and_spaces/config_trial.ts:
38.2 minutes\r\n```\r\n\r\nAfter
split:\r\nx-pack/test/spaces_api_integration/security_and_spaces/config_basic.ts\r\n20m
29s\r\n\r\nx-pack/test/spaces_api_integration/security_and_spaces/copy_to_space_config_basic.ts\r\n20m
52s\r\nx-pack/test/spaces_api_integration/security_and_spaces/config_trial.ts\r\n19m
57s\r\n\r\nx-pack/test/spaces_api_integration/security_and_spaces/copy_to_space_config_trial.ts\r\n21m
5s\r\n\r\nRebalancing it with other configs should speedup CI by at
least
few\r\nminutes","sha":"424eae3f4d0f55f684a5b3c3b46847eb723233c9"}},"sourceBranch":"main","suggestedTargetBranches":["8.8","8.7"],"targetPullRequestStates":[{"branch":"8.8","label":"v8.8.0","labelRegex":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"},{"branch":"8.7","label":"v8.7.2","labelRegex":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"},{"branch":"main","label":"v8.9.0","labelRegex":"^v8.9.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/156350","number":156350,"mergeCommit":{"message":"[functional
tests] split security and spaces ftr configs (#156350)\n\n##
Summary\r\n\r\nSplitting ftr configs to speed up ftr tests run on CI
\r\n\r\n```\r\nThe following \"Functional Tests\" configs have durations
that exceed the maximum amount of time desired for a single CI job.
\r\nThis is not an error, and if you don't own any of these configs then
you can ignore this warning.If you own any of these\r\nconfigs please
split them up ASAP and ask Operations if you have questions about how to
do
that.\r\n\r\nx-pack/test/spaces_api_integration/security_and_spaces/config_basic.ts:
38.2
minutes\r\nx-pack/test/spaces_api_integration/security_and_spaces/config_trial.ts:
38.2 minutes\r\n```\r\n\r\nAfter
split:\r\nx-pack/test/spaces_api_integration/security_and_spaces/config_basic.ts\r\n20m
29s\r\n\r\nx-pack/test/spaces_api_integration/security_and_spaces/copy_to_space_config_basic.ts\r\n20m
52s\r\nx-pack/test/spaces_api_integration/security_and_spaces/config_trial.ts\r\n19m
57s\r\n\r\nx-pack/test/spaces_api_integration/security_and_spaces/copy_to_space_config_trial.ts\r\n21m
5s\r\n\r\nRebalancing it with other configs should speedup CI by at
least
few\r\nminutes","sha":"424eae3f4d0f55f684a5b3c3b46847eb723233c9"}}]}]
BACKPORT-->
Co-authored-by: Dzmitry Lemechko <dzmitry.lemechko@elastic.co>
# Backport
This will backport the following commits from `main` to `8.7`:
- [[lens] split x-pack/test/functional/apps/lens/group3/config.ts into
smaller groups (#155860)](https://github.com/elastic/kibana/pull/155860)
<!--- Backport version: 8.9.7 -->
### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sqren/backport)
<!--BACKPORT [{"author":{"name":"Dzmitry
Lemechko","email":"dzmitry.lemechko@elastic.co"},"sourceCommit":{"committedDate":"2023-04-27T18:14:41Z","message":"[lens]
split x-pack/test/functional/apps/lens/group3/config.ts into smaller
groups (#155860)\n\n## Summary\r\n\r\n\r\nRe-grouping lens functional
tests into 6 groups since 2 groups often\r\ncross the 35+ min runtime.
Also, we have retry in place so pipeline\r\nmight have +40 minutes run
if any of test fails.\r\n\r\n<img width=\"1354\"
alt=\"image\"\r\nsrc=\"https://user-images.githubusercontent.com/10977896/234843379-aec47a81-22dc-4ecf-aee5-b1d489b3b31f.png\">\r\n\r\nx-pack/test/functional/apps/lens/group1/config.ts
18m 42s\r\nx-pack/test/functional/apps/lens/group2/config.ts 19m
26s\r\nx-pack/test/functional/apps/lens/group3/config.ts 18m
26s\r\nx-pack/test/functional/apps/lens/group4/config.ts 18m
40s\r\nx-pack/test/functional/apps/lens/group5/config.ts 17m
55s\r\nx-pack/test/functional/apps/lens/group6/config.ts 19m
24s\r\n\r\n---------\r\n\r\nCo-authored-by: Jon
<jon@budzenski.me>","sha":"483edea966bfdd0d801ad28d5b681ca008a45ec8","branchLabelMapping":{"^v8.9.0$":"main","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:skip","v8.8.0","v8.7.2","v8.9.0"],"number":155860,"url":"https://github.com/elastic/kibana/pull/155860","mergeCommit":{"message":"[lens]
split x-pack/test/functional/apps/lens/group3/config.ts into smaller
groups (#155860)\n\n## Summary\r\n\r\n\r\nRe-grouping lens functional
tests into 6 groups since 2 groups often\r\ncross the 35+ min runtime.
Also, we have retry in place so pipeline\r\nmight have +40 minutes run
if any of test fails.\r\n\r\n<img width=\"1354\"
alt=\"image\"\r\nsrc=\"https://user-images.githubusercontent.com/10977896/234843379-aec47a81-22dc-4ecf-aee5-b1d489b3b31f.png\">\r\n\r\nx-pack/test/functional/apps/lens/group1/config.ts
18m 42s\r\nx-pack/test/functional/apps/lens/group2/config.ts 19m
26s\r\nx-pack/test/functional/apps/lens/group3/config.ts 18m
26s\r\nx-pack/test/functional/apps/lens/group4/config.ts 18m
40s\r\nx-pack/test/functional/apps/lens/group5/config.ts 17m
55s\r\nx-pack/test/functional/apps/lens/group6/config.ts 19m
24s\r\n\r\n---------\r\n\r\nCo-authored-by: Jon
<jon@budzenski.me>","sha":"483edea966bfdd0d801ad28d5b681ca008a45ec8"}},"sourceBranch":"main","suggestedTargetBranches":["8.7"],"targetPullRequestStates":[{"branch":"8.8","label":"v8.8.0","labelRegex":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"url":"https://github.com/elastic/kibana/pull/156075","number":156075,"state":"MERGED","mergeCommit":{"sha":"1a79030dbf17b08eb893e3bd7812e7b849a668bc","message":"[8.8]
[lens] split x-pack/test/functional/apps/lens/group3/config.ts into
smaller groups (#155860) (#156075)\n\n# Backport\n\nThis will backport
the following commits from `main` to `8.8`:\n- [[lens] split
x-pack/test/functional/apps/lens/group3/config.ts into\nsmaller groups
(#155860)](https://github.com/elastic/kibana/pull/155860)\n\n<!---
Backport version: 8.9.7 -->\n\n### Questions ?\nPlease refer to the
[Backport
tool\ndocumentation](https://github.com/sqren/backport)\n\n<!--BACKPORT
[{\"author\":{\"name\":\"Dzmitry\nLemechko\",\"email\":\"dzmitry.lemechko@elastic.co\"},\"sourceCommit\":{\"committedDate\":\"2023-04-27T18:14:41Z\",\"message\":\"[lens]\nsplit
x-pack/test/functional/apps/lens/group3/config.ts into smaller\ngroups
(#155860)\\n\\n## Summary\\r\\n\\r\\n\\r\\nRe-grouping lens
functional\ntests into 6 groups since 2 groups often\\r\\ncross the 35+
min runtime.\nAlso, we have retry in place so pipeline\\r\\nmight have
+40 minutes run\nif any of test fails.\\r\\n\\r\\n<img
width=\\\"1354\\\"\nalt=\\\"image\\\"\\r\\nsrc=\\\"https://user-images.githubusercontent.com/10977896/234843379-aec47a81-22dc-4ecf-aee5-b1d489b3b31f.png\\\">\\r\\n\\r\\nx-pack/test/functional/apps/lens/group1/config.ts\n18m
42s\\r\\nx-pack/test/functional/apps/lens/group2/config.ts
19m\n26s\\r\\nx-pack/test/functional/apps/lens/group3/config.ts
18m\n26s\\r\\nx-pack/test/functional/apps/lens/group4/config.ts
18m\n40s\\r\\nx-pack/test/functional/apps/lens/group5/config.ts
17m\n55s\\r\\nx-pack/test/functional/apps/lens/group6/config.ts
19m\n24s\\r\\n\\r\\n---------\\r\\n\\r\\nCo-authored-by:
Jon\n<jon@budzenski.me>\",\"sha\":\"483edea966bfdd0d801ad28d5b681ca008a45ec8\",\"branchLabelMapping\":{\"^v8.9.0$\":\"main\",\"^v(\\\\d+).(\\\\d+).\\\\d+$\":\"$1.$2\"}},\"sourcePullRequest\":{\"labels\":[\"release_note:skip\",\"v8.8.0\",\"v8.7.2\",\"v8.9.0\"],\"number\":155860,\"url\":\"https://github.com/elastic/kibana/pull/155860\",\"mergeCommit\":{\"message\":\"[lens]\nsplit
x-pack/test/functional/apps/lens/group3/config.ts into smaller\ngroups
(#155860)\\n\\n## Summary\\r\\n\\r\\n\\r\\nRe-grouping lens
functional\ntests into 6 groups since 2 groups often\\r\\ncross the 35+
min runtime.\nAlso, we have retry in place so pipeline\\r\\nmight have
+40 minutes run\nif any of test fails.\\r\\n\\r\\n<img
width=\\\"1354\\\"\nalt=\\\"image\\\"\\r\\nsrc=\\\"https://user-images.githubusercontent.com/10977896/234843379-aec47a81-22dc-4ecf-aee5-b1d489b3b31f.png\\\">\\r\\n\\r\\nx-pack/test/functional/apps/lens/group1/config.ts\n18m
42s\\r\\nx-pack/test/functional/apps/lens/group2/config.ts
19m\n26s\\r\\nx-pack/test/functional/apps/lens/group3/config.ts
18m\n26s\\r\\nx-pack/test/functional/apps/lens/group4/config.ts
18m\n40s\\r\\nx-pack/test/functional/apps/lens/group5/config.ts
17m\n55s\\r\\nx-pack/test/functional/apps/lens/group6/config.ts
19m\n24s\\r\\n\\r\\n---------\\r\\n\\r\\nCo-authored-by:
Jon\n<jon@budzenski.me>\",\"sha\":\"483edea966bfdd0d801ad28d5b681ca008a45ec8\"}},\"sourceBranch\":\"main\",\"suggestedTargetBranches\":[\"8.8\",\"8.7\"],\"targetPullRequestStates\":[{\"branch\":\"8.8\",\"label\":\"v8.8.0\",\"labelRegex\":\"^v(\\\\d+).(\\\\d+).\\\\d+$\",\"isSourceBranch\":false,\"state\":\"NOT_CREATED\"},{\"branch\":\"8.7\",\"label\":\"v8.7.2\",\"labelRegex\":\"^v(\\\\d+).(\\\\d+).\\\\d+$\",\"isSourceBranch\":false,\"state\":\"NOT_CREATED\"},{\"branch\":\"main\",\"label\":\"v8.9.0\",\"labelRegex\":\"^v8.9.0$\",\"isSourceBranch\":true,\"state\":\"MERGED\",\"url\":\"https://github.com/elastic/kibana/pull/155860\",\"number\":155860,\"mergeCommit\":{\"message\":\"[lens]\nsplit
x-pack/test/functional/apps/lens/group3/config.ts into smaller\ngroups
(#155860)\\n\\n## Summary\\r\\n\\r\\n\\r\\nRe-grouping lens
functional\ntests into 6 groups since 2 groups often\\r\\ncross the 35+
min runtime.\nAlso, we have retry in place so pipeline\\r\\nmight have
+40 minutes run\nif any of test fails.\\r\\n\\r\\n<img
width=\\\"1354\\\"\nalt=\\\"image\\\"\\r\\nsrc=\\\"https://user-images.githubusercontent.com/10977896/234843379-aec47a81-22dc-4ecf-aee5-b1d489b3b31f.png\\\">\\r\\n\\r\\nx-pack/test/functional/apps/lens/group1/config.ts\n18m
42s\\r\\nx-pack/test/functional/apps/lens/group2/config.ts
19m\n26s\\r\\nx-pack/test/functional/apps/lens/group3/config.ts
18m\n26s\\r\\nx-pack/test/functional/apps/lens/group4/config.ts
18m\n40s\\r\\nx-pack/test/functional/apps/lens/group5/config.ts
17m\n55s\\r\\nx-pack/test/functional/apps/lens/group6/config.ts
19m\n24s\\r\\n\\r\\n---------\\r\\n\\r\\nCo-authored-by:
Jon\n<jon@budzenski.me>\",\"sha\":\"483edea966bfdd0d801ad28d5b681ca008a45ec8\"}}]}]\nBACKPORT-->\n\nCo-authored-by:
Dzmitry Lemechko
<dzmitry.lemechko@elastic.co>"}},{"branch":"8.7","label":"v8.7.2","labelRegex":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"},{"branch":"main","label":"v8.9.0","labelRegex":"^v8.9.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/155860","number":155860,"mergeCommit":{"message":"[lens]
split x-pack/test/functional/apps/lens/group3/config.ts into smaller
groups (#155860)\n\n## Summary\r\n\r\n\r\nRe-grouping lens functional
tests into 6 groups since 2 groups often\r\ncross the 35+ min runtime.
Also, we have retry in place so pipeline\r\nmight have +40 minutes run
if any of test fails.\r\n\r\n<img width=\"1354\"
alt=\"image\"\r\nsrc=\"https://user-images.githubusercontent.com/10977896/234843379-aec47a81-22dc-4ecf-aee5-b1d489b3b31f.png\">\r\n\r\nx-pack/test/functional/apps/lens/group1/config.ts
18m 42s\r\nx-pack/test/functional/apps/lens/group2/config.ts 19m
26s\r\nx-pack/test/functional/apps/lens/group3/config.ts 18m
26s\r\nx-pack/test/functional/apps/lens/group4/config.ts 18m
40s\r\nx-pack/test/functional/apps/lens/group5/config.ts 17m
55s\r\nx-pack/test/functional/apps/lens/group6/config.ts 19m
24s\r\n\r\n---------\r\n\r\nCo-authored-by: Jon
<jon@budzenski.me>","sha":"483edea966bfdd0d801ad28d5b681ca008a45ec8"}}]}]
BACKPORT-->
Backport of https://github.com/elastic/kibana/pull/153159.
(cherry picked from commit
d1dff0b2c7)
Closes#149342.
It accomplishes this by returning the ArchivePackage, unzipped bundled
package that includes most of the same fields as the RegistryPackage.
These fields are used in APM to support the fleet migration workflow.
# Backport
This will backport the following commits from `main` to `8.7`:
- [Split scalability pipelines
(#151915)](https://github.com/elastic/kibana/pull/151915)
<!--- Backport version: 8.9.7 -->
### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sqren/backport)
<!--BACKPORT [{"author":{"name":"Dzmitry
Lemechko","email":"dzmitry.lemechko@elastic.co"},"sourceCommit":{"committedDate":"2023-02-24T11:52:57Z","message":"Split
scalability pipelines (#151915)\n\n## Summary\r\n\r\nAs a POC single api
capacity testing pipeline was sharing pipeline steps\r\n& main script
with scalability journey.\r\nThis pipeline does not build Kibana
sources, but downloads existing\r\nKibana build and run tests against
it.\r\n\r\nThis PR moves capacity testing in its own script and its own
pipeline\r\nthat includes building Kibana sources and testing your
changes.\r\n\r\ncc @afharo \r\n\r\nIt should be possible to test your
Kibana changes for apis
performance\r\nimprovements.","sha":"18fbb946aa33d784c5fcbf26545587b91afffb28","branchLabelMapping":{"^v8.8.0$":"main","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:skip","v8.7.0","v8.8.0","v8.6.3"],"number":151915,"url":"https://github.com/elastic/kibana/pull/151915","mergeCommit":{"message":"Split
scalability pipelines (#151915)\n\n## Summary\r\n\r\nAs a POC single api
capacity testing pipeline was sharing pipeline steps\r\n& main script
with scalability journey.\r\nThis pipeline does not build Kibana
sources, but downloads existing\r\nKibana build and run tests against
it.\r\n\r\nThis PR moves capacity testing in its own script and its own
pipeline\r\nthat includes building Kibana sources and testing your
changes.\r\n\r\ncc @afharo \r\n\r\nIt should be possible to test your
Kibana changes for apis
performance\r\nimprovements.","sha":"18fbb946aa33d784c5fcbf26545587b91afffb28"}},"sourceBranch":"main","suggestedTargetBranches":["8.7","8.6"],"targetPullRequestStates":[{"branch":"8.7","label":"v8.7.0","labelRegex":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"},{"branch":"main","label":"v8.8.0","labelRegex":"^v8.8.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/151915","number":151915,"mergeCommit":{"message":"Split
scalability pipelines (#151915)\n\n## Summary\r\n\r\nAs a POC single api
capacity testing pipeline was sharing pipeline steps\r\n& main script
with scalability journey.\r\nThis pipeline does not build Kibana
sources, but downloads existing\r\nKibana build and run tests against
it.\r\n\r\nThis PR moves capacity testing in its own script and its own
pipeline\r\nthat includes building Kibana sources and testing your
changes.\r\n\r\ncc @afharo \r\n\r\nIt should be possible to test your
Kibana changes for apis
performance\r\nimprovements.","sha":"18fbb946aa33d784c5fcbf26545587b91afffb28"}},{"branch":"8.6","label":"v8.6.3","labelRegex":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"}]}]
BACKPORT-->
Co-authored-by: Dzmitry Lemechko <dzmitry.lemechko@elastic.co>
# Backport
This will backport the following commits from `main` to `8.7`:
- [[artifacts/container image] Only trigger on main branch
(#151050)](https://github.com/elastic/kibana/pull/151050)
<!--- Backport version: 8.9.7 -->
### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sqren/backport)
<!--BACKPORT
[{"author":{"name":"Jon","email":"jon@elastic.co"},"sourceCommit":{"committedDate":"2023-02-13T21:50:45Z","message":"[artifacts/container
image] Only trigger on main branch (#151050)\n\nWe only need to product
container images for the most recent commit.\r\nThis updates the trigger
to only run on `main`.\r\n\r\nnote: `skip-ci` label, this only runs
on-merge and is a no-op from
pull\r\nrequests.","sha":"f1046e55c17685781110a11d2842afcbd6a2efa4","branchLabelMapping":{"^v8.8.0$":"main","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["Team:Operations","release_note:skip","skip-ci","backport:prev-minor","v8.8.0"],"number":151050,"url":"https://github.com/elastic/kibana/pull/151050","mergeCommit":{"message":"[artifacts/container
image] Only trigger on main branch (#151050)\n\nWe only need to product
container images for the most recent commit.\r\nThis updates the trigger
to only run on `main`.\r\n\r\nnote: `skip-ci` label, this only runs
on-merge and is a no-op from
pull\r\nrequests.","sha":"f1046e55c17685781110a11d2842afcbd6a2efa4"}},"sourceBranch":"main","suggestedTargetBranches":[],"targetPullRequestStates":[{"branch":"main","label":"v8.8.0","labelRegex":"^v8.8.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/151050","number":151050,"mergeCommit":{"message":"[artifacts/container
image] Only trigger on main branch (#151050)\n\nWe only need to product
container images for the most recent commit.\r\nThis updates the trigger
to only run on `main`.\r\n\r\nnote: `skip-ci` label, this only runs
on-merge and is a no-op from
pull\r\nrequests.","sha":"f1046e55c17685781110a11d2842afcbd6a2efa4"}}]}]
BACKPORT-->
Co-authored-by: Jon <jon@elastic.co>
# Backport
This will backport the following commits from `main` to `8.7`:
- [[ftr] split x-pack api integration tests based on plugin
(#150837)](https://github.com/elastic/kibana/pull/150837)
<!--- Backport version: 8.9.7 -->
### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sqren/backport)
<!--BACKPORT [{"author":{"name":"Dzmitry
Lemechko","email":"dzmitry.lemechko@elastic.co"},"sourceCommit":{"committedDate":"2023-02-13T15:06:11Z","message":"[ftr]
split x-pack api integration tests based on plugin (#150837)\n\n##
Summary\r\n\r\nCurrently we run all x-pack api integration tests as a
single piece\r\n(config) and it takes on average **33+ minutes**\r\nIf a
single test fails, buildkite retries the config and you have to\r\nwait
another 30+ minutes to see if test passed (flaky test sign) or\r\nfailed
(PR broke test)\r\n\r\n<img width=\"1581\"
alt=\"image\"\r\nsrc=\"https://user-images.githubusercontent.com/10977896/218059268-1d4b5b40-797d-4748-a9f6-9101cfd9803a.png\">\r\n\r\n\r\nSplitting
config into many small ones will not only speedup overall CI\r\nrun
(configs will be assigned to different workers based on
its\r\nhistorical run time) but also speedup retry by running only a sub
set of\r\ntests related to the particular config
file.\r\n\r\n---------\r\n\r\nCo-authored-by: Kibana Machine
<42973632+kibanamachine@users.noreply.github.com>","sha":"745e9ad9d7d1a3958842bfe63343e2e4d00041f6","branchLabelMapping":{"^v8.8.0$":"main","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:skip","v8.7.0","v8.8.0"],"number":150837,"url":"https://github.com/elastic/kibana/pull/150837","mergeCommit":{"message":"[ftr]
split x-pack api integration tests based on plugin (#150837)\n\n##
Summary\r\n\r\nCurrently we run all x-pack api integration tests as a
single piece\r\n(config) and it takes on average **33+ minutes**\r\nIf a
single test fails, buildkite retries the config and you have to\r\nwait
another 30+ minutes to see if test passed (flaky test sign) or\r\nfailed
(PR broke test)\r\n\r\n<img width=\"1581\"
alt=\"image\"\r\nsrc=\"https://user-images.githubusercontent.com/10977896/218059268-1d4b5b40-797d-4748-a9f6-9101cfd9803a.png\">\r\n\r\n\r\nSplitting
config into many small ones will not only speedup overall CI\r\nrun
(configs will be assigned to different workers based on
its\r\nhistorical run time) but also speedup retry by running only a sub
set of\r\ntests related to the particular config
file.\r\n\r\n---------\r\n\r\nCo-authored-by: Kibana Machine
<42973632+kibanamachine@users.noreply.github.com>","sha":"745e9ad9d7d1a3958842bfe63343e2e4d00041f6"}},"sourceBranch":"main","suggestedTargetBranches":["8.7"],"targetPullRequestStates":[{"branch":"8.7","label":"v8.7.0","labelRegex":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"},{"branch":"main","label":"v8.8.0","labelRegex":"^v8.8.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/150837","number":150837,"mergeCommit":{"message":"[ftr]
split x-pack api integration tests based on plugin (#150837)\n\n##
Summary\r\n\r\nCurrently we run all x-pack api integration tests as a
single piece\r\n(config) and it takes on average **33+ minutes**\r\nIf a
single test fails, buildkite retries the config and you have to\r\nwait
another 30+ minutes to see if test passed (flaky test sign) or\r\nfailed
(PR broke test)\r\n\r\n<img width=\"1581\"
alt=\"image\"\r\nsrc=\"https://user-images.githubusercontent.com/10977896/218059268-1d4b5b40-797d-4748-a9f6-9101cfd9803a.png\">\r\n\r\n\r\nSplitting
config into many small ones will not only speedup overall CI\r\nrun
(configs will be assigned to different workers based on
its\r\nhistorical run time) but also speedup retry by running only a sub
set of\r\ntests related to the particular config
file.\r\n\r\n---------\r\n\r\nCo-authored-by: Kibana Machine
<42973632+kibanamachine@users.noreply.github.com>","sha":"745e9ad9d7d1a3958842bfe63343e2e4d00041f6"}}]}]
BACKPORT-->
Co-authored-by: Dzmitry Lemechko <dzmitry.lemechko@elastic.co>
## Summary
Splitting config as it takes over 40 minutes into smaller ones to
speedup CI
```
The following "Functional Tests" configs have durations that exceed the maximum amount of time desired for a single CI job. This is not an error, and if you don't own any of these configs then you can ignore this warning.If you own any of these configs please split them up ASAP and ask Operations if you have questions about how to do that.
x-pack/test/functional_with_es_ssl/config.ts: 40.6 minutes
```
Quick tests execution time
[analysis](https://buildkite.com/elastic/kibana-pull-request/builds/105995#01862b40-f797-4537-9e05-a56453173b6d):
/apps/triggers_actions_ui ~ 13 min
09:01:15 CEST - 09:14:10 CEST
/apps/discover ~ 6 min
09:14:10 CEST - 09:20:21 CEST
/apps/uptime. ~ 2 min
09:20:21 CEST - 09:22:08 CEST
/apps/ml ~1 min
09:22:08 CEST - 09:22:57 CEST
/apps/cases ~ 17 min
09:23:02 CEST - 09:40:19 CEST
Splitting into 3 groups:
x-pack/test/functional_with_es_ssl/apps/triggers_actions_ui/config.ts
12m 46s
x-pack/test/functional_with_es_ssl/apps/cases/config.ts 18m 07s
x-pack/test/functional_with_es_ssl/apps/discover_ml_uptime/config.ts 10m
38s
Splitting cases/config into 2 groups:
x-pack/test/functional_with_es_ssl/apps/cases/group1/config.ts 10m 18s
x-pack/test/functional_with_es_ssl/apps/cases/group2/config.ts 8m 58s
We're seeing parse errors of `DOCKER_BUILDKIT` after a version update.
This variable should either be unset or a boolean. Instead of using an
empty string this sets it to 1.
Previously a custom diff of the files inside the upstream `spec`
directory was kept up-to-date in this package `.patches` directory. This
process was very tedious and wasn't providing much value.
In this commit I've simplified the process tremendously and simply rely on
checking if there are any new commits upstream and then allow the
developer to manually check for relevant changes. This is something they
needed to do with the old system regardless. Here the code is just much
simpler.
---------
Co-authored-by: Aleh Zasypkin <aleh.zasypkin@gmail.com>
## Summary
Trying to address slow config issue:
```
The following "Functional Tests" configs have durations that exceed the maximum amount of time desired for a single CI job. This is not an error, and if you don't own any of these configs then you can ignore this warning.If you own any of these configs please split them up ASAP and ask Operations if you have questions about how to do that.
x-pack/test/alerting_api_integration/spaces_only/config.ts: 41.4 minutes
```
by splitting it into multiple groups.
_1 round (splitting main index file with 3 index suites where each one
has its own setup/tearDown + alerting suite into 4 groups)_
x-pack/test/alerting_api_integration/spaces_only/tests/alerting/group1/config.ts
7m 1s
x-pack/test/alerting_api_integration/spaces_only/tests/alerting/group2/config.ts
**15m 10s**
x-pack/test/alerting_api_integration/spaces_only/tests/alerting/group3/config.ts
**21m 40s**
x-pack/test/alerting_api_integration/spaces_only/tests/alerting/group4/config.ts
5m 30s
x-pack/test/alerting_api_integration/spaces_only/tests/action_task_params/config.ts
2m 31s
x-pack/test/alerting_api_integration/spaces_only/tests/actions/config.ts
4m 22s
_2 round (rebalance groups 1-4 to be more time equal)_
x-pack/test/alerting_api_integration/spaces_only/tests/alerting/group1/config.ts
12m 46s
x-pack/test/alerting_api_integration/spaces_only/tests/alerting/group2/config.ts
8m 46s
x-pack/test/alerting_api_integration/spaces_only/tests/alerting/group3/config.ts
17m 30s
x-pack/test/alerting_api_integration/spaces_only/tests/alerting/group4/config.ts
9m 5s
Here `Alerting eventLog alerts should generate expected alert events for
normal operation` test started to fail, probably there is a dependency
on the previous tests.
_3 round (rebalance groups 1-4, to keep tests order in group 1 up until
`event_log.ts` suite)_
x-pack/test/alerting_api_integration/spaces_only/tests/alerting/group1/config.ts
17m 12s
x-pack/test/alerting_api_integration/spaces_only/tests/alerting/group2/config.ts
8m 28s
x-pack/test/alerting_api_integration/spaces_only/tests/alerting/group3/config.ts
16m 15s
x-pack/test/alerting_api_integration/spaces_only/tests/alerting/group4/config.ts
6m 21s
_4 round (rebalancing groups 3-4 to be more time equal)_
x-pack/test/alerting_api_integration/spaces_only/tests/alerting/group1/config.ts
**17m 14s**
x-pack/test/alerting_api_integration/spaces_only/tests/alerting/group2/config.ts
**8m 37s**
x-pack/test/alerting_api_integration/spaces_only/tests/alerting/group3/config.ts
**12m 40s**
x-pack/test/alerting_api_integration/spaces_only/tests/alerting/group4/config.ts
**9m 49s**
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This PR attempts to fix config duration time warning
```
The following "Functional Tests" configs have durations that exceed the maximum amount of time desired for a single CI job. This is not an error, and if you don't own any of these configs then you can ignore this warning.If you own any of these configs please split them up ASAP and ask Operations if you have questions about how to do that.
x-pack/test/functional_basic/config.ts: 38.8 minutes
```
<img width="1188" alt="image"
src="https://user-images.githubusercontent.com/10977896/214912243-800a1c80-13fa-406b-93dd-0f5ab208cda9.png">
PR initially splits original test suite into 3 config files based on
area: permission, data visualizer and transform.
- x-pack/test/functional_basic/apps/ml/data_visualizer/config.ts
duration: **19m 24s** (left for later)
- x-pack/test/functional_basic/apps/transform/config.ts duration: **18m
14s** -> let's split in 5 configs
- x-pack/test/functional_basic/apps/ml/permissions/config.ts. duration:
5m 10s
2nd split round:
-
x-pack/test/functional_basic/apps/transform/feature_controls/config.ts.
duration: 2m 4s
- x-pack/test/functional_basic/apps/transform/group1/config.ts duration:
**8m 16s** -> let's split in 2 configs
- x-pack/test/functional_basic/apps/transform/group2/config.ts.
duration: 5m 20s
- x-pack/test/functional_basic/apps/transform/group3/config.ts.
duration: 5m 12s
- x-pack/test/functional_basic/apps/ml/permissions/config.ts. duration:
5m 10s -> let's split in 3 configs (1 test file each)
3rd split round:
- x-pack/test/functional_basic/apps/ml/permissions/group1/config.ts.
duration: 3m 11s
- x-pack/test/functional_basic/apps/ml/permissions/group2/config.ts
duration: 3m 42s
- x-pack/test/functional_basic/apps/ml/permissions/group3/config.ts
duration 2m 14s
- x-pack/test/functional_basic/apps/transform/group4/config.ts duration:
4m 43s
lets split into 3 configs
- x-pack/test/functional_basic/apps/ml/data_visualizer/config.ts
duration: **19m 24s**
4th split round:
- x-pack/test/functional_basic/apps/ml/data_visualizer/group1/config.ts
duration: 4m 42s
- x-pack/test/functional_basic/apps/ml/data_visualizer/group2/config.ts
duration: 9m 27s
- x-pack/test/functional_basic/apps/ml/data_visualizer/group3/config.ts
duration: 7m 39s
[Build time
](https://buildkite.com/elastic/kibana-pull-request/builds/103355) is
49m 26sec (55 FTR groups)
Currently on-merge pipeline for
[main](https://buildkite.com/elastic/kibana-on-merge/builds?branch=main)
takes around 1h
## Summary
This PR only deletes the component from the UI action plugin.
@semd has already added the component to a new package here
https://github.com/elastic/kibana/pull/149057
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Fix https://github.com/elastic/kibana/issues/148412
More and more SO types will not be accessible from the HTTP APIs (either
`hidden:true` or `hiddenFromHTTPApis: true`).
However, the FTR SO client (`KbnClientSavedObjects`) still needs to be
able to access and manipulate all SO types.
This PR introduces a `ftrSoApis` plugin that is loaded for all FTR
suites. This plugin exposes SO APIs that are used by the FTR client
instead of the public SO HTTP APIs. These APIs are configured to know
about all types, even hidden ones.
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
We just had an issue where two PRs were merged and it caused the limit
of the `triggerActionsUi` bundle to be exceeded, breaking PR builds. The
issue is that we didn't see any indication of this in the on-merge jobs
because we don't produce the PR report for on-merge jobs or ask ci-stats
if we should fail the job. Instead, we just ship the metrics for
baseline purposes. This fixes that problem by adding a `--validate` flag
to `node scripts/ship_ci_stats`, which takes care of sending at least
some ci-stats and will verify that the bundle limits are not exceeded.
Since we didn't catch this issue in the on-merge job the limits were
incorrect for over an hour and merged into many PRs, wasting engineering
and CI time.
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Reopens#149143 with updates to the target file and service
After a commit is merged, tested, and images are built and pushed to the
container registry we need to send a notification that a new tag is
available.
This triggers a promotion pipeline with the latest container tag when:
1) the branch is tracked (i.e. main, and not a personal branch) 1)
~triggered from our on-merge test pipeline.~
https://github.com/elastic/kibana/pull/149350 had to remove support for
this - we're triggering via REST now which removes the from trigger
environment variable.
After a commit is merged, tested, and images are built and pushed to the
container registry we need to send a notification that a new tag is
available.
This triggers a promotion pipeline with the latest container tag when:
1) the branch is tracked (i.e. main, and not a personal branch)
1) ~triggered from our on-merge test pipeline.~
https://github.com/elastic/kibana/pull/149350 had to remove support for
this - we're triggering via REST now which removes the from trigger
environment variable.
Co-authored-by: Tiago Costa <tiago.costa@elastic.co>
Reopens#148864 to trigger via REST instead of yaml. The previous
implementation did not support commit triggered builds.
This conditionally adds a pipeline trigger to
`kibana-artifacts-container-image` at the end of the on-merge pipeline
when tests are passing. The triggered pipeline will build (and
eventually push) our default docker images.
## Summary
I noticed some noise in [Performance
dashboard](dd0473ac-826f-5621-9a10-25319700326e?_g=(filters:!(),refreshInterval:(pause:!t,value:0),time:(from:now-24h%2Fh,to:now)))
and think it is better to disable Telemetry for journeys by default.
We use it to report performance events and this PR enables it in the
performance pipeline via env variable `PERFORMANCE_ENABLE_TELEMETRY`.
For other pipelines (PRs,
[performance-data-set-extraction](https://buildkite.com/elastic/kibana-performance-data-set-extraction))
running on regular workers or local troubleshooting there is no much
value to collect inconsistent values.
This adds a new pipeline to build our default container image, using the
`kibana-ci` docker namespace and the docker version based on the first 7
digits of the commit hash.
https://buildkite.com/elastic/kibana-artifacts-container-image/builds/3
Will have followups for:
1) on-merge trigger
2) docker push / controller pipeline trigger
need to make sure branches other than main, and manual triggers
(untested) skip publishing.
FTR groups on CI target a 40 minute runtime. In situations where tests
are updated or moved, and there's no prior data, we're seeing occasional
timeouts with a 60 minute timeout. This increases the timeout to 90
minutes.
Updates mocha to 10.2.0 and types/mocha to 10.0.1 to address an `npm
audit` warning. Verified tests still run and pass.
Re-opens https://github.com/elastic/kibana/pull/146951 with a fix added
to `package.json`. Credits to the original author, thanks for the
contribution.
Co-authored-by: Sergev ₱ <118327710+iot-defcon@users.noreply.github.com>
This PR implements a linter like the TS Project linter, except for
packages in the repo. It does this by extracting the reusable bits from
the TS Project linter and reusing them for the project linter. The only
rule that exists for packages right now is that the "name" in the
package.json file matches the "id" in Kibana.jsonc. The goal is to use a
rule to migrate kibana.json files on the future.
Additionally, a new rule for validating the indentation of tsconfig.json
files was added.
Validating and fixing violations is what has triggered review by so many
teams, but we plan to treat those review requests as notifications of
the changes and not as blockers for merging.
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This PR adds capability to run capacity testing for single apis #143066
Currently in main we have to 2 types of performance tests:
- single user performance journey that simulates single end-user
experience in browser
- scalability journey that uses APM traces from single user performance
journey to simulate multiple end-users experience
This new type of performance tests allow to better understand how each
single server api scale under the similar load.
How to run locally:
make sure to clone the latest main branch of
[elastic/kibana-load-testing](https://github.com/elastic/kibana-load-testing)
in Kibana repo run:
`node scripts/run_scalability.js --journey-path
x-pack/test/scalability/apis/api.core.capabilities.json`
How it works:
FTR is used to start Kibana/ES and run Gatling simulation with json file
as input. After run the latest report matching journey name is parsed to
get perf metrics and report using EBT to the Telemetry cluster.
How will it run after merge:
I plan to run pipeline every 3 hours on bare metal machine and report
metrics to Telemetry staging cluster.
<img width="2023" alt="image"
src="https://user-images.githubusercontent.com/10977896/208771628-f4f5dbcb-cb73-40c6-9aa1-4ec3fbf5285b.png">
APM traces are collected and reported to Kibana stats cluster:
<img width="1520" alt="image"
src="https://user-images.githubusercontent.com/10977896/208771323-4cca531a-eeea-4941-8b01-50b890f932b1.png">
What metrics are collected:
1. warmupAvgResponseTime - average response time during warmup phase
2. rpsAtWarmup - average requests per second during warmup phase
3. warmupDuration
4. responseTimeMetric (default: 85%) Gatling has response time
25/50/75/80/85/90/95/99 percentiles, as well as min/max values
5. threshold1ResponseTime (default 3000 ms)
6. rpsAtThreshold1 requests per second when `responseTimeMetric` first
reach threshold1ResponseTime
7. threshold2ResponseTime
8. rpsAtThreshold2 (default 9000 ms)
9. threshold3ResponseTime
10. rpsAtThreshold3 (default 15000 ms)
As long as we agree on metrics I will update indexer for telemetry.
Co-authored-by: Alejandro Fernández Haro <alejandro.haro@elastic.co>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
### Summary
**Sets up the foundations for
https://github.com/elastic/kibana/issues/146000**
- created a new test server under
`x-pack/test/monitoring_api_integration/` that allows loading of
packages at kibana startup
- a test runner utility which is a simple for loop executing the
supplied test twice, one time with `metricbeat` data and a second time
with `package` data
- a utility that allows transformation of package data into metricbeat
data
**Adds API tests for the beats package**
- created a test case for each API exposed
- removed the duplicates from
`x-pack/test/api_integration/apis/monitoring`
-----
_See the included
[README](b55de5c1cc/x-pack/test/monitoring_api_integration/README.md)
for additional details_
This directory defines a custom test server that provides bundled
integrations
packages to the spawned test Kibana. This allows us to install those
packages at
startup, with all their assets (index templates, ingest pipelines..),
without
having to reach a remote package registry.
With the packages and their templates already installed we don't have to
provide
the static mappings in the tests archives. This has the benefit of
reducing our
disk footprint and setup time but more importantly it enables an easy
upgrade path
of the mappings so we can verify no breaking changes were introduced by
bundling
the new versions of the packages.
_Note that while Stack Monitoring currently supports 3 collection modes,
the tests
in this directory only focus on metricbeat and elastic-agent data. Tests
for legacy
data are defined under `x-pack/test/api_integration/apis/monitoring`._
Since an elastic-agent integration spawns the corresponding metricbeat
module under
the hood (ie when an agent policy defines elasticsearch metrics data
streams,
a metricbeat process with the elasticsearch module will be spawned), the
output
documents are _almost_ identical. This means that we can easily
transform documents
from a source (elastic-agent) to another (metricbeat), and have the same
tests run
against both datasets.
Note that we don't have to install anything for the metricbeat data
since the mappings
are already installed by elasticseach at startup, and available at
`.monitoring-<component>-8-mb`
patterns. So we are always running the metricbeat tests against the
latest version of
the mappings.
We could have a similar approach for packages, for example by installing
the latest
packages versions from public EPR before the test suites run, instead of
using pinned
versions. Besides the questionable reliance on remote services for
running tests,
this is also dangerous given that packages are released in a continuous
model.
This means that whenever the test suite would execute against the latest
version
of packages it would be too late, as in already available to users.
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
The new images have an updated gh binary which now requires setting the
`GITHUB_REPO` env var, or calling `gh repo set-default`. I opted for the
env var so that we didn't need to find a good time to execute the CLI
(after the keys are in the env, but before all other user code) or worry
about the logging. This also allows other users of our scripts to
customize as makes sense without having to dive into a bunch of
imperative shell code.
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
