[pull] main from elastic:main #741
Merged
Conversation
This file contains 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
![pull[bot]](https://avatars.githubusercontent.com/in/12910?s=60&v=4){kind=small}
This PR updates the function definitions and inline docs based on the latest metadata from Elasticsearch.
) ## Summary Assign test files to security-defend-workflows team Contributes to: #192979 Co-authored-by: Elastic Machine <[email protected]>
Part of #200858 This PR updates the ES|QL grammars (lexer and parser) to match the latest version in Elasticsearch. --------- Co-authored-by: Stratoula Kalafateli <[email protected]>
## Summary Closes #193352 Update: Using a new SO field `bump_agent_policy_revision` in package policy type to mark package policies for update, this will trigger an agent policy revision bump. The feature supports both legacy and new package policy SO types, and queries policies from all spaces. To test, add a model version change to the package policy type and save. After Fleet setup is run, the agent policies using the package policies should be bumped and deployed. The same effect can be achieved by manually updating a package policy SO and loading Fleet UI to trigger setup. ``` '2': { changes: [ { type: 'data_backfill', backfillFn: (doc) => { return { attributes: { ...doc.attributes, bump_agent_policy_revision: true } }; }, }, ], }, curl -sk -XPOST --user fleet_superuser:password -H 'content-type:application/json' \ -H'x-elastic-product-origin:fleet' \ http://localhost:9200/.kibana_ingest/_update_by_query -d ' { "query": { "match": { "type": "fleet-package-policies" } },"script": { "source": "ctx._source[\"fleet-package-policies\"].bump_agent_policy_revision = true", "lang": "painless" } }' ``` ``` [2024-11-20T14:40:30.064+01:00][INFO ][plugins.fleet] Found 1 package policies that need agent policy revision bump [2024-11-20T14:40:31.933+01:00][DEBUG][plugins.fleet] Updated 1 package policies in space space1 in 1869ms, bump 1 agent policies [2024-11-20T14:40:35.056+01:00][DEBUG][plugins.fleet] Deploying 1 policies [2024-11-20T14:40:35.493+01:00][DEBUG][plugins.fleet] Deploying policies: 7f108cf2-4cf0-4a11-8df4-fc69d00a3484:10 ``` TODO: - the same flag has to be added on agent policy and output types, and the task extended to update them - I plan to do this in another pr, so that this doesn't become too big - add integration test if possible ### Scale testing Tested with 500 agent policies split to 2 spaces, 1 integration per policy and bumping the flag in a new saved object model version, the bump task took about 6s. The deploy policies step is async, took about 30s. ``` [2024-11-20T15:53:55.628+01:00][INFO ][plugins.fleet] Found 501 package policies that need agent policy revision bump [2024-11-20T15:53:57.881+01:00][DEBUG][plugins.fleet] Updated 250 package policies in space space1 in 2253ms, bump 250 agent policies [2024-11-20T15:53:59.926+01:00][DEBUG][plugins.fleet] Updated 251 package policies in space default in 4298ms, bump 251 agent policies [2024-11-20T15:54:01.186+01:00][DEBUG][plugins.fleet] Deploying 250 policies [2024-11-20T15:54:29.989+01:00][DEBUG][plugins.fleet] Deploying policies: test-policy-space1-1:4, ... [2024-11-20T15:54:33.538+01:00][DEBUG][plugins.fleet] Deploying policies: policy-elastic-agent-on-cloud:4, test-policy-default-1:4, ... ``` ### Checklist - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios --------- Co-authored-by: kibanamachine <[email protected]>
…ce (#201407) Part of #193245 Related #200226 Closes #200743 ## Summary This PR completes the migration of remaining Service Overview tests to the Deployment Agnostic test framework. In this PR, one test was deduplicated (the Dependencies test), and the Instances Detailed Statistics cases dealing with archiver data was migrated to make use of synthtrace instead. Snapshots included were redone to match the data generated by synthtrace, but no other cases were changed to ensure the new migrated tests were passing the same assumptions as before. ## How to Test ### Serverless ``` node scripts/functional_tests_server --config x-pack/test/api_integration/deployment_agnostic/configs/serverless/oblt/apm.serverless.config.ts node scripts/functional_test_runner --config x-pack/test/api_integration/deployment_agnostic/configs/serverless/oblt.apm.serverless.config.ts ``` It's recommended to be run against [MKI](https://github.com/crespocarlos/kibana/blob/main/x-pack/test_serverless/README.md#run-tests-on-mki) ### Stateful ``` node scripts/functional_tests_server --config x-pack/test/api_integration/deployment_agnostic/configs/stateful/oblt.apm.stateful.config.ts node scripts/functional_test_runner --config x-pack/test/api_integration/deployment_agnostic/configs/stateful/oblt.apm.stateful.config.ts ``` --------- Co-authored-by: jennypavlova <[email protected]> Co-authored-by: Elastic Machine <[email protected]>
… obs-ux-logs-team (#201148) This PR migrates test suites that use `renderHook` from the library `@testing-library/react-hooks` to adopt the equivalent and replacement of `renderHook` from the export that is now available from `@testing-library/react`. This work is required for the planned migration to react18. ## Context In this PR, usages of `waitForNextUpdate` that previously could have been destructured from `renderHook` are now been replaced with `waitFor` exported from `@testing-library/react`, furthermore `waitFor` that would also have been destructured from the same renderHook result is now been replaced with `waitFor` from the export of `@testing-library/react`. ***Why is `waitFor` a sufficient enough replacement for `waitForNextUpdate`, and better for testing values subject to async computations?*** WaitFor will retry the provided callback if an error is returned, till the configured timeout elapses. By default the retry interval is `50ms` with a timeout value of `1000ms` that effectively translates to at least 20 retries for assertions placed within waitFor. See https://testing-library.com/docs/dom-testing-library/api-async/#waitfor for more information. This however means that for person's writing tests, said person has to be explicit about expectations that describe the internal state of the hook being tested. This implies checking for instance when a react query hook is being rendered, there's an assertion that said hook isn't loading anymore. In this PR you'd notice that this pattern has been adopted, with most existing assertions following an invocation of `waitForNextUpdate` being placed within a `waitFor` invocation. In some cases the replacement is simply a `waitFor(() => new Promise((resolve) => resolve(null)))` (many thanks to @kapral18, for point out exactly why this works), where this suffices the assertions that follow aren't placed within a waitFor so this PR doesn't get larger than it needs to be. It's also worth pointing out this PR might also contain changes to test and application code to improve said existing test. ### What to do next? 1. Review the changes in this PR. 2. If you think the changes are correct, approve the PR. ## Any questions? If you have any questions or need help with this PR, please leave comments in this PR. Co-authored-by: Elastic Machine <[email protected]>
… tests for failing case (#201517) ## Summary Currently, the partitionPatchRequest in x-pack/plugins/cases/server/client/cases/bulk_update.ts will not check a case properly if a case is being re-opened, instead of an else if in the loop comparing cases to cases in the request, the status logic should be outside of this set of if statements. If a case is being re-opened, the final else is never run, and casesToAuthorize is 0. This results in ensureAuthorized being called with an empty array of entities, and so the check always succeeds. To fix this, reopenedCases is still populated in the same loop, just not when casesToAuthorize logic is running as well. Also adds some missing tests for this and the create comment permission as requested in #194898. ### Checklist - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios
… kibana-management (#201146) This PR migrates test suites that use `renderHook` from the library `@testing-library/react-hooks` to adopt the equivalent and replacement of `renderHook` from the export that is now available from `@testing-library/react`. This work is required for the planned migration to react18. ## Context In this PR, usages of `waitForNextUpdate` that previously could have been destructured from `renderHook` are now been replaced with `waitFor` exported from `@testing-library/react`, furthermore `waitFor` that would also have been destructured from the same renderHook result is now been replaced with `waitFor` from the export of `@testing-library/react`. ***Why is `waitFor` a sufficient enough replacement for `waitForNextUpdate`, and better for testing values subject to async computations?*** WaitFor will retry the provided callback if an error is returned, till the configured timeout elapses. By default the retry interval is `50ms` with a timeout value of `1000ms` that effectively translates to at least 20 retries for assertions placed within waitFor. See https://testing-library.com/docs/dom-testing-library/api-async/#waitfor for more information. This however means that for person's writing tests, said person has to be explicit about expectations that describe the internal state of the hook being tested. This implies checking for instance when a react query hook is being rendered, there's an assertion that said hook isn't loading anymore. In this PR you'd notice that this pattern has been adopted, with most existing assertions following an invocation of `waitForNextUpdate` being placed within a `waitFor` invocation. In some cases the replacement is simply a `waitFor(() => new Promise((resolve) => resolve(null)))` (many thanks to @kapral18, for point out exactly why this works), where this suffices the assertions that follow aren't placed within a waitFor so this PR doesn't get larger than it needs to be. It's also worth pointing out this PR might also contain changes to test and application code to improve said existing test. ### What to do next? 1. Review the changes in this PR. 2. If you think the changes are correct, approve the PR. ## Any questions? If you have any questions or need help with this PR, please leave comments in this PR. Co-authored-by: Elastic Machine <[email protected]>
…rations using auto-detect flow (#201158) Resolves #199751 ## Summary Use Fleet's default data output when onboarding integrations using auto-detect flow. ## Screenshot ### Fleet output settings <img width="1411" alt="Screenshot 2024-11-21 at 15 10 24" src="https://github.com/user-attachments/assets/ac193552-7f18-4566-a84b-061df45c13f3"> ### Generated Agent config ``` $ cat /Library/Elastic/Agent/elastic-agent.yml outputs: default: type: elasticsearch hosts: - https://192.168.1.73:9200 ssl.ca_trusted_fingerprint: c48c98cdf7f85d7cc29f834704011c1002b5251d594fc0bb08e6177544fe304a api_key: b1BkR1Q1TUIyOUpfMWhaS2NCUXA6SS1Jb3dncGVReVNpcEdzOGpSVmlzQQ== preset: balanced ``` ## Testing 1. Go to Fleet > Settings > Outputs 2. Edit the default output and enter dummy data into the "Elasticsearch CA trusted fingerprint" field 3. Go through the auto-detect onboarding flow 4. Inspect the `elastic-agent.yml` file written to disk. It should contain the default output configured in Fleet including `ca_trusted_fingerprint` setting
## Summary Assign test files to core team Contributes to: #192979
## Summary The test failed again after the last fix. I added `within` to try and improve the time of the dom traversals in the failing test.
Closes #200769 ## Summary This PR is a follow-up to #199854 and it adds the following code improvements: - Replaces Mappings-editor-context-level property `hasEnterpriceLicense` with plugin-context-level `canUseSyntheticSource` property - Adds jest tests to check if the synthetic option is correctly displayed based on license - Improves readability of serializer logic for the source field **How to test:** The same test instructions from #199854 can be followed with a focus on checking that the synthetic option is only available in Enterprise license.
…g transaction duration alerts returns the correct number of alert counts (#201533) ## Summary Related to #201531 This PR skips `Transaction groups alerts when data is loaded with avg transaction duration alerts returns the correct number of alert counts`, which is inside `x-pack/test/api_integration/deployment_agnostic/apis/observability/apm/transactions/transactions_groups_alerts.spec.ts` file, as it's failing on MKI.
…1251) ## Summary Closes #193827 This PR improves the space selector in agent policy setting to handle the case where the user does not have access to all policy spaces. In this case: * Space selection is disabled * The "Create space" link is hidden * A tooltip is shown to inform the user why the input is disabled * The inaccessible space badges are given an `Unavailable space` badge ### Screenshots For a user with access to all policy spaces (no change):  For a user with access to only a subset of policy spaces:  ### Checklist - [x] Any text added follows [EUI's writing guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses sentence case text and includes [i18n support](https://github.com/elastic/kibana/blob/main/packages/kbn-i18n/README.md) - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios - [x] The PR description includes the appropriate Release Notes section, and the correct `release_note:*` label is applied per the [guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process) --------- Co-authored-by: Elastic Machine <[email protected]>
…201351) ## Summary Closes #201346 This PR adds a `dat` dev script, which lets you easily run APM deployment-agnostic tests, as we already do with `api` tests. ## Examples Run only server with stateful config ```sh node x-pack/plugins/observability_solution/apm/scripts/test/dat --stateful --server ``` Run only runner with stateful config ```sh node x-pack/plugins/observability_solution/apm/scripts/test/dat --stateful --runner ``` Run everything with serverless config ```sh node x-pack/plugins/observability_solution/apm/scripts/test/dat --serverless ``` More information [here](https://github.com/elastic/kibana/pull/201351/files#diff-5ca943bbe3962fc31cce510407cc1563a959b0fdb9cb52619f57e1f182a9751a) --------- Co-authored-by: Cauê Marcondes <[email protected]>
…01548) ## Summary This PR filters the fields containing `@` in date type from `script` processor. ## Before this PR  ```json { "script": { "tag": "script_convert_array_to_string", "description": "Ensures the date processor does not receive an array value.", "lang": "painless", "source": "if (ctx.varonis?.varonis_alerts?.@timestamp != null &&\n ctx.varonis.varonis_alerts.@timestamp instanceof ArrayList){\n ctx.varonis.varonis_alerts.@timestamp = ctx.varonis.varonis_alerts.@timestamp[0];\n}\n" } }, { "date": { "if": "ctx.varonis?.varonis_alerts?.@timestamp != null", "tag": "date_processor_varonis.varonis_alerts.@timestamp", "field": "varonis.varonis_alerts.@timestamp", "target_field": "event.start", "formats": [ "yyyy-MM-dd'T'HH:mm:ss.SSS'Z'", "ISO8601" ] } }, ``` ## After this PR ```json "date": { "if": "ctx.varonis?.varonis_alerts?.@timestamp != null", "tag": "date_processor_varonis.varonis_alerts.@timestamp", "field": "varonis.varonis_alerts.@timestamp", "target_field": "event.start", "formats": [ "yyyy-MM-dd'T'HH:mm:ss.SSS'Z'", "ISO8601" ] } }, ``` ### Checklist Check the PR satisfies following conditions. Reviewers should verify this PR satisfies this list as well. - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios
## Summary Assign test files to viz team Contributes to: #192979 --------- Co-authored-by: Elastic Machine <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.1)
Can you help keep this open source service alive? 💖 Please sponsor : )