[9.0] [scout] use project deps as global hooks for parallel tests (#211409)#214645
Merged
dmlemeshko merged 2 commits intoelastic:9.0from Mar 18, 2025
Merged
[9.0] [scout] use project deps as global hooks for parallel tests (#211409)#214645dmlemeshko merged 2 commits intoelastic:9.0from
dmlemeshko merged 2 commits intoelastic:9.0from
Conversation
…211409) ## Summary Currently we are using `globalSetup` [script in configuration file](https://playwright.dev/docs/test-global-setup-teardown#option-2-configure-globalsetup-and-globalteardown) to ingest Elasticsearch data before running the tests in parallel against the same ES/Kibana instances. This approach doesn't work well when you need to adjust `globalSetup` logic based on specific condition, e.g. configuration file defining where servers are hosted, its credentials, etc. Not only global hook, but `ScoutConfig` fixture expects an argument to define where servers configuration is defined: https://github.com/elastic/kibana/blob/cd502acea12979979497f62897be663044ade3aa/packages/kbn-scout/src/playwright/fixtures/worker/core_fixtures.ts#L65-L75 `testInfo` is how Playwright exposes currently running configuration in a form of `project` interface: [projects](https://playwright.dev/docs/test-projects) can be used to group tests, e.g. for specific envs or browsers. Unfortunately `testInfo` is not exposed in global scripts, because in Playwright project design `globalSetup` scripts are run before multiple projects and projects can have its own `setup` hooks via [dependencies](https://playwright.dev/docs/test-global-setup-teardown#option-1-project-dependencies): ``` { name: 'setup', testMatch: /global.setup\.ts/, }, { name: 'local', use: { ...devices['Desktop Chrome'], configName: 'local' }, dependencies: 'setup', }, ``` We already use project API to get `serversConfigDir` path, where we plan to store local and cloud server configurations. This PR proposes to define projects as `local` and `cloud` (maybe even separate `cloud-mki`, `cloud-ech`) as a way to provide playwright information about servers configuration. Advantages: 1. we can re-use existing fixtures as-is, without adding custom exported helper functions for ES data ingestion 2. project dependency is displayed as `setup` in Playwright report 3. way better and simpler design for consumers: ``` import { globalSetupHook } from '@kbn/scout'; globalSetupHook('Ingest data to Elasticsearch', async ({ esArchiver, log }) => { // add archives to load, if needed const archives = [ testData.ES_ARCHIVES.LOGSTASH, ]; log.debug('[setup] loading test data (only if indexes do not exist)...'); for (const archive of archives) { await esArchiver.loadIfNeeded(archive); } }); ``` 4. it is supported by VSCode Playwright plugin <img width="1271" alt="Screenshot 2025-02-17 at 11 26 12" src="https://github.com/user-attachments/assets/ba7eeb38-d39d-4785-9c11-18647599ec4a" /> I find it extremely useful because you don't need to change env var when you want to switch b/w local or cloud run, all the configurations are loaded automatically and you just tick the checkbox! Disadvantages: 1. it is important to run `playwright test` with `--project` flag to use the proper configuration 2. we have to define how `projects` are used for local and cloud configuration, and make sure it meets requirements of multiple teams. We can expose a way to pass custom project definitions in `createPlaywrightConfig` function, but it might complicate the support effort when every Team has too many custom projects. 3. `project` term is something we can't change and might be confusing 4. Since it is a Playwright feature, we might not have consistency with API tests runner under Scout For reviewers: Playing with it locally might give a better understanding about the pros/cons, especially with IDE playwright plugin installed. Running servers with tests: ``` node scripts/scout.js run-tests --serverless=oblt --testTarget=local --config x-pack/platform/plugins/private/discover_enhanced/ui_tests/playwright.config.ts node scripts/scout.js run-tests --serverless=oblt --config x-pack/platform/plugins/private/discover_enhanced/ui_tests/playwright.config.ts ``` Running test only requires passing `project` argument: ``` npx playwright test --project=local --config x-pack/platform/plugins/private/discover_enhanced/ui_tests/playwright.config.ts npx playwright test --project=local --config x-pack/platform/plugins/private/discover_enhanced/ui_tests/parallel.playwright.config.ts ``` --------- Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com> Co-authored-by: jennypavlova <jennypavlova94@gmail.com> (cherry picked from commit 1b30686) # Conflicts: # x-pack/platform/plugins/shared/triggers_actions_ui/public/application/sections/field_browser/index.ts # x-pack/solutions/observability/plugins/apm/ui_tests/README.md # x-pack/solutions/observability/plugins/apm/ui_tests/fixtures/index.ts # x-pack/solutions/observability/plugins/apm/ui_tests/fixtures/page_objects/service_inventory.ts # x-pack/solutions/observability/plugins/apm/ui_tests/fixtures/page_objects/service_map.ts # x-pack/solutions/observability/plugins/apm/ui_tests/fixtures/synthtrace/opbeans.ts # x-pack/solutions/observability/plugins/apm/ui_tests/parallel_tests/global_setup.ts # x-pack/solutions/observability/plugins/apm/ui_tests/parallel_tests/service_inventory/service_inventory.spec.ts # x-pack/solutions/observability/plugins/apm/ui_tests/parallel_tests/sevice_map/service_map.spec.ts # x-pack/solutions/observability/plugins/apm/ui_tests/tsconfig.json
Contributor
💚 Build Succeeded
Metrics [docs]Public APIs missing comments
Unknown metric groupsAPI count
ESLint disabled line counts
Total ESLint disabled count
History
|
dmlemeshko
added a commit
that referenced
this pull request
Mar 19, 2025
…11409) (#215066) # Backport This will backport the following commits from `main` to `8.x`: - [[scout] use project deps as global hooks for parallel tests (#211409)](#211409) <!--- Backport version: 9.6.6 --> ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sorenlouv/backport) <!--BACKPORT [{"author":{"name":"Dzmitry Lemechko","email":"dzmitry.lemechko@elastic.co"},"sourceCommit":{"committedDate":"2025-03-13T09:06:26Z","message":"[scout] use project deps as global hooks for parallel tests (#211409)\n\n## Summary\n\nCurrently we are using `globalSetup` [script in configuration\nfile](https://playwright.dev/docs/test-global-setup-teardown#option-2-configure-globalsetup-and-globalteardown)\nto ingest Elasticsearch data before running the tests in parallel\nagainst the same ES/Kibana instances.\n\nThis approach doesn't work well when you need to adjust `globalSetup`\nlogic based on specific condition, e.g. configuration file defining\nwhere servers are hosted, its credentials, etc.\n\nNot only global hook, but `ScoutConfig` fixture expects an argument to\ndefine where servers configuration is defined:\n\n\nhttps://github.com/elastic/kibana/blob/cd502acea12979979497f62897be663044ade3aa/packages/kbn-scout/src/playwright/fixtures/worker/core_fixtures.ts#L65-L75\n\n`testInfo` is how Playwright exposes currently running configuration in\na form of `project` interface:\n[projects](https://playwright.dev/docs/test-projects) can be used to\ngroup tests, e.g. for specific envs or browsers.\n\nUnfortunately `testInfo` is not exposed in global scripts, because in\nPlaywright project design `globalSetup` scripts are run before multiple\nprojects and projects can have its own `setup` hooks via\n[dependencies](https://playwright.dev/docs/test-global-setup-teardown#option-1-project-dependencies):\n\n```\n {\n name: 'setup',\n testMatch: /global.setup\\.ts/,\n },\n {\n name: 'local',\n use: { ...devices['Desktop Chrome'], configName: 'local' },\n dependencies: 'setup',\n },\n``` \n\nWe already use project API to get `serversConfigDir` path, where we plan\nto store local and cloud server configurations. This PR proposes to\ndefine projects as `local` and `cloud` (maybe even separate `cloud-mki`,\n`cloud-ech`) as a way to provide playwright information about servers\nconfiguration.\n\nAdvantages:\n1. we can re-use existing fixtures as-is, without adding custom exported\nhelper functions for ES data ingestion\n2. project dependency is displayed as `setup` in Playwright report\n3. way better and simpler design for consumers:\n```\nimport { globalSetupHook } from '@kbn/scout';\n\nglobalSetupHook('Ingest data to Elasticsearch', async ({ esArchiver, log }) => {\n // add archives to load, if needed\n const archives = [\n testData.ES_ARCHIVES.LOGSTASH,\n ];\n\n log.debug('[setup] loading test data (only if indexes do not exist)...');\n for (const archive of archives) {\n await esArchiver.loadIfNeeded(archive);\n }\n});\n```\n4. it is supported by VSCode Playwright plugin\n<img width=\"1271\" alt=\"Screenshot 2025-02-17 at 11 26 12\"\nsrc=\"https://github.com/user-attachments/assets/ba7eeb38-d39d-4785-9c11-18647599ec4a\"\n/>\n\nI find it extremely useful because you don't need to change env var when\nyou want to switch b/w local or cloud run, all the configurations are\nloaded automatically and you just tick the checkbox!\n\nDisadvantages:\n1. it is important to run `playwright test` with `--project` flag to use\nthe proper configuration\n2. we have to define how `projects` are used for local and cloud\nconfiguration, and make sure it meets requirements of multiple teams. We\ncan expose a way to pass custom project definitions in\n`createPlaywrightConfig` function, but it might complicate the support\neffort when every Team has too many custom projects.\n3. `project` term is something we can't change and might be confusing\n4. Since it is a Playwright feature, we might not have consistency with\nAPI tests runner under Scout\n\nFor reviewers: \n\nPlaying with it locally might give a better understanding about the\npros/cons, especially with IDE playwright plugin installed.\n\nRunning servers with tests:\n```\nnode scripts/scout.js run-tests --serverless=oblt --testTarget=local --config x-pack/platform/plugins/private/discover_enhanced/ui_tests/playwright.config.ts\n\nnode scripts/scout.js run-tests --serverless=oblt --config x-pack/platform/plugins/private/discover_enhanced/ui_tests/playwright.config.ts\n```\n\nRunning test only requires passing `project` argument:\n\n```\nnpx playwright test --project=local --config x-pack/platform/plugins/private/discover_enhanced/ui_tests/playwright.config.ts\n\nnpx playwright test --project=local --config x-pack/platform/plugins/private/discover_enhanced/ui_tests/parallel.playwright.config.ts\n```\n\n---------\n\nCo-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>\nCo-authored-by: jennypavlova <jennypavlova94@gmail.com>","sha":"1b30686181df5410e92983ede4002ac5f693a164","branchLabelMapping":{"^v9.1.0$":"main","^v8.19.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:skip","v9.0.0","Team:obs-ux-infra_services","backport:version","test:scout","v9.1.0","v8.19.0"],"title":"[scout] use project deps as global hooks for parallel tests","number":211409,"url":"https://github.com/elastic/kibana/pull/211409","mergeCommit":{"message":"[scout] use project deps as global hooks for parallel tests (#211409)\n\n## Summary\n\nCurrently we are using `globalSetup` [script in configuration\nfile](https://playwright.dev/docs/test-global-setup-teardown#option-2-configure-globalsetup-and-globalteardown)\nto ingest Elasticsearch data before running the tests in parallel\nagainst the same ES/Kibana instances.\n\nThis approach doesn't work well when you need to adjust `globalSetup`\nlogic based on specific condition, e.g. configuration file defining\nwhere servers are hosted, its credentials, etc.\n\nNot only global hook, but `ScoutConfig` fixture expects an argument to\ndefine where servers configuration is defined:\n\n\nhttps://github.com/elastic/kibana/blob/cd502acea12979979497f62897be663044ade3aa/packages/kbn-scout/src/playwright/fixtures/worker/core_fixtures.ts#L65-L75\n\n`testInfo` is how Playwright exposes currently running configuration in\na form of `project` interface:\n[projects](https://playwright.dev/docs/test-projects) can be used to\ngroup tests, e.g. for specific envs or browsers.\n\nUnfortunately `testInfo` is not exposed in global scripts, because in\nPlaywright project design `globalSetup` scripts are run before multiple\nprojects and projects can have its own `setup` hooks via\n[dependencies](https://playwright.dev/docs/test-global-setup-teardown#option-1-project-dependencies):\n\n```\n {\n name: 'setup',\n testMatch: /global.setup\\.ts/,\n },\n {\n name: 'local',\n use: { ...devices['Desktop Chrome'], configName: 'local' },\n dependencies: 'setup',\n },\n``` \n\nWe already use project API to get `serversConfigDir` path, where we plan\nto store local and cloud server configurations. This PR proposes to\ndefine projects as `local` and `cloud` (maybe even separate `cloud-mki`,\n`cloud-ech`) as a way to provide playwright information about servers\nconfiguration.\n\nAdvantages:\n1. we can re-use existing fixtures as-is, without adding custom exported\nhelper functions for ES data ingestion\n2. project dependency is displayed as `setup` in Playwright report\n3. way better and simpler design for consumers:\n```\nimport { globalSetupHook } from '@kbn/scout';\n\nglobalSetupHook('Ingest data to Elasticsearch', async ({ esArchiver, log }) => {\n // add archives to load, if needed\n const archives = [\n testData.ES_ARCHIVES.LOGSTASH,\n ];\n\n log.debug('[setup] loading test data (only if indexes do not exist)...');\n for (const archive of archives) {\n await esArchiver.loadIfNeeded(archive);\n }\n});\n```\n4. it is supported by VSCode Playwright plugin\n<img width=\"1271\" alt=\"Screenshot 2025-02-17 at 11 26 12\"\nsrc=\"https://github.com/user-attachments/assets/ba7eeb38-d39d-4785-9c11-18647599ec4a\"\n/>\n\nI find it extremely useful because you don't need to change env var when\nyou want to switch b/w local or cloud run, all the configurations are\nloaded automatically and you just tick the checkbox!\n\nDisadvantages:\n1. it is important to run `playwright test` with `--project` flag to use\nthe proper configuration\n2. we have to define how `projects` are used for local and cloud\nconfiguration, and make sure it meets requirements of multiple teams. We\ncan expose a way to pass custom project definitions in\n`createPlaywrightConfig` function, but it might complicate the support\neffort when every Team has too many custom projects.\n3. `project` term is something we can't change and might be confusing\n4. Since it is a Playwright feature, we might not have consistency with\nAPI tests runner under Scout\n\nFor reviewers: \n\nPlaying with it locally might give a better understanding about the\npros/cons, especially with IDE playwright plugin installed.\n\nRunning servers with tests:\n```\nnode scripts/scout.js run-tests --serverless=oblt --testTarget=local --config x-pack/platform/plugins/private/discover_enhanced/ui_tests/playwright.config.ts\n\nnode scripts/scout.js run-tests --serverless=oblt --config x-pack/platform/plugins/private/discover_enhanced/ui_tests/playwright.config.ts\n```\n\nRunning test only requires passing `project` argument:\n\n```\nnpx playwright test --project=local --config x-pack/platform/plugins/private/discover_enhanced/ui_tests/playwright.config.ts\n\nnpx playwright test --project=local --config x-pack/platform/plugins/private/discover_enhanced/ui_tests/parallel.playwright.config.ts\n```\n\n---------\n\nCo-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>\nCo-authored-by: jennypavlova <jennypavlova94@gmail.com>","sha":"1b30686181df5410e92983ede4002ac5f693a164"}},"sourceBranch":"main","suggestedTargetBranches":["8.x"],"targetPullRequestStates":[{"branch":"9.0","label":"v9.0.0","branchLabelMappingKey":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"url":"https://github.com/elastic/kibana/pull/214645","number":214645,"state":"MERGED","mergeCommit":{"sha":"1101afbf997857637543419abb56415e41c2edec","message":"[9.0] [scout] use project deps as global hooks for parallel tests (#211409) (#214645)\n\n# Backport\n\nThis will backport the following commits from `main` to `9.0`:\n- [[scout] use project deps as global hooks for parallel tests\n(#211409)](https://github.com/elastic/kibana/pull/211409)\n\n\n\n### Questions ?\nPlease refer to the [Backport tool\ndocumentation](https://github.com/sorenlouv/backport)\n\n"}},{"branch":"main","label":"v9.1.0","branchLabelMappingKey":"^v9.1.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/211409","number":211409,"mergeCommit":{"message":"[scout] use project deps as global hooks for parallel tests (#211409)\n\n## Summary\n\nCurrently we are using `globalSetup` [script in configuration\nfile](https://playwright.dev/docs/test-global-setup-teardown#option-2-configure-globalsetup-and-globalteardown)\nto ingest Elasticsearch data before running the tests in parallel\nagainst the same ES/Kibana instances.\n\nThis approach doesn't work well when you need to adjust `globalSetup`\nlogic based on specific condition, e.g. configuration file defining\nwhere servers are hosted, its credentials, etc.\n\nNot only global hook, but `ScoutConfig` fixture expects an argument to\ndefine where servers configuration is defined:\n\n\nhttps://github.com/elastic/kibana/blob/cd502acea12979979497f62897be663044ade3aa/packages/kbn-scout/src/playwright/fixtures/worker/core_fixtures.ts#L65-L75\n\n`testInfo` is how Playwright exposes currently running configuration in\na form of `project` interface:\n[projects](https://playwright.dev/docs/test-projects) can be used to\ngroup tests, e.g. for specific envs or browsers.\n\nUnfortunately `testInfo` is not exposed in global scripts, because in\nPlaywright project design `globalSetup` scripts are run before multiple\nprojects and projects can have its own `setup` hooks via\n[dependencies](https://playwright.dev/docs/test-global-setup-teardown#option-1-project-dependencies):\n\n```\n {\n name: 'setup',\n testMatch: /global.setup\\.ts/,\n },\n {\n name: 'local',\n use: { ...devices['Desktop Chrome'], configName: 'local' },\n dependencies: 'setup',\n },\n``` \n\nWe already use project API to get `serversConfigDir` path, where we plan\nto store local and cloud server configurations. This PR proposes to\ndefine projects as `local` and `cloud` (maybe even separate `cloud-mki`,\n`cloud-ech`) as a way to provide playwright information about servers\nconfiguration.\n\nAdvantages:\n1. we can re-use existing fixtures as-is, without adding custom exported\nhelper functions for ES data ingestion\n2. project dependency is displayed as `setup` in Playwright report\n3. way better and simpler design for consumers:\n```\nimport { globalSetupHook } from '@kbn/scout';\n\nglobalSetupHook('Ingest data to Elasticsearch', async ({ esArchiver, log }) => {\n // add archives to load, if needed\n const archives = [\n testData.ES_ARCHIVES.LOGSTASH,\n ];\n\n log.debug('[setup] loading test data (only if indexes do not exist)...');\n for (const archive of archives) {\n await esArchiver.loadIfNeeded(archive);\n }\n});\n```\n4. it is supported by VSCode Playwright plugin\n<img width=\"1271\" alt=\"Screenshot 2025-02-17 at 11 26 12\"\nsrc=\"https://github.com/user-attachments/assets/ba7eeb38-d39d-4785-9c11-18647599ec4a\"\n/>\n\nI find it extremely useful because you don't need to change env var when\nyou want to switch b/w local or cloud run, all the configurations are\nloaded automatically and you just tick the checkbox!\n\nDisadvantages:\n1. it is important to run `playwright test` with `--project` flag to use\nthe proper configuration\n2. we have to define how `projects` are used for local and cloud\nconfiguration, and make sure it meets requirements of multiple teams. We\ncan expose a way to pass custom project definitions in\n`createPlaywrightConfig` function, but it might complicate the support\neffort when every Team has too many custom projects.\n3. `project` term is something we can't change and might be confusing\n4. Since it is a Playwright feature, we might not have consistency with\nAPI tests runner under Scout\n\nFor reviewers: \n\nPlaying with it locally might give a better understanding about the\npros/cons, especially with IDE playwright plugin installed.\n\nRunning servers with tests:\n```\nnode scripts/scout.js run-tests --serverless=oblt --testTarget=local --config x-pack/platform/plugins/private/discover_enhanced/ui_tests/playwright.config.ts\n\nnode scripts/scout.js run-tests --serverless=oblt --config x-pack/platform/plugins/private/discover_enhanced/ui_tests/playwright.config.ts\n```\n\nRunning test only requires passing `project` argument:\n\n```\nnpx playwright test --project=local --config x-pack/platform/plugins/private/discover_enhanced/ui_tests/playwright.config.ts\n\nnpx playwright test --project=local --config x-pack/platform/plugins/private/discover_enhanced/ui_tests/parallel.playwright.config.ts\n```\n\n---------\n\nCo-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>\nCo-authored-by: jennypavlova <jennypavlova94@gmail.com>","sha":"1b30686181df5410e92983ede4002ac5f693a164"}},{"branch":"8.x","label":"v8.19.0","branchLabelMappingKey":"^v8.19.0$","isSourceBranch":false,"state":"NOT_CREATED"}]}] BACKPORT-->
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Backport
This will backport the following commits from
mainto9.0:Questions ?
Please refer to the Backport tool documentation