## Summary
The UI & Integrations team is moving to a new GitHub project. This PR
updates our automation to automatically place issues in the new project
instead of the old one.
## Summary
Last merge to this file included a broken line, mistakenly.
This PR fixes that.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
### Ownership Assigned
- Various files for my team.
- `x-pack/test_serverless/functional/test_suites/security/cypress` to
security solution 🤞🏾
-
`/x-pack/test_serverless/functional/page_objects/svl_ingest_pipelines.ts`
to search team due to [this
pr](https://github.com/elastic/kibana/pull/180422).
- From this pr, I decided to add more ownership based on the contents.
-
`/x-pack/test_serverless/functional/page_objects/svl_management_page.ts`
from [this pr](https://github.com/elastic/kibana/pull/176200/files)
- From this pr, I decided to add more ownership based on the contents.
- Also, as I was in the "security" realm so to speak, I started adding
more files for the security solution team
-
`x-pack/test_serverless/functional/test_suites/security/screenshot_creation/index.ts`
to response ops due to this
[pr](https://github.com/elastic/kibana/pull/174556)
Contributes to: https://github.com/elastic/kibana/issues/194815
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Related https://github.com/elastic/kibana/issues/193473
Add initial implementation of the knowledge base artifact builder. This
PR only introduces the builder script, it doesn't do anything about
automation.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
In an attempt to make Reviewing easier and more accurate, the
implementation of Vulnerabilities on Host.name flyout in Alerts Page
will be split into 2 Phases
Phase 1: Move Functions, Utils or Helpers, Hooks, constants to Package
Phase 2: Implementing the feature
This is Phase 2
<img width="1465" alt="Screenshot 2024-09-20 at 5 33 01 PM"
src="https://github.com/user-attachments/assets/cabe2f3a-d35a-4825-9fe5-61fe2d570328">
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Maxim Kholod <maxim.kholod@elastic.co>
## Summary
Modify code owner declarations for
`x-pack/test/functional/es_archives/auditbeat/**/*` in
.github/CODEOWNERS
### For reviewers
To verify this pr, you can use the `scripts/get_owners_for_file.js`
script
E.g:
```
node scripts/get_owners_for_file.js --file x-pack/test/functional/es_archives/auditbeat/users # Or any other file
```
#### Notes
All of these are a best guess effort. The more help from the dev teams,
the more accurate this will be for reporting in the future.
Contributes to: https://github.com/elastic/kibana/issues/192979
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
Fixes https://github.com/elastic/kibana/issues/175298
Improve synthetics alerting !!
User will be able to create custom synthetics status alert by defining
three kind of criteria
### Monitor is down over last consective checks with threshold
<img width="639" alt="image"
src="390da238-f7f2-4eb0-9606-3279b3199fdf">
### From Locations threshold
Will be considered down only when from defined number of locations
<img width="618" alt="image"
src="24741a10-0880-4247-9048-8ce03df25bf5">
### Over time with checks threshold just like uptime custom status alert
<img width="631" alt="image"
src="64e1c808-8d4b-4dd0-b794-eb7f4e5d1e6b">
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Dominique Clarke <dominique.clarke@elastic.co>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: Maryam Saeidi <maryam.saeidi@elastic.co>
Co-authored-by: Justin Kambic <jk@elastic.co>
## Summary
fixes: https://github.com/elastic/security-team/issues/10235
fixes: https://github.com/elastic/security-team/issues/10237
This is the final PR for migrating over all timeline-related schemas and
types to the new generated zod schemas from our OpenAPI specs. (see
https://github.com/elastic/security-team/issues/10110)
On top of moving to the new schemas/types, this PR also cleans up usage
of now outdated types.
I'm aware of the size of this PR but rest assured, the changes are easy
to review and for most teams, only a handful of files need to be
reviewed:
```markdown
### elastic/security-defend-workflows
* x-pack/test/security_solution_endpoint/apps/endpoint/endpoint_solution_integrations.ts
### elastic/security-detection-rule-management
* x-pack/plugins/security_solution/server/lib/detection_engine/prebuilt_rules/api/get_prebuilt_rules_and_timelines_status/get_prebuilt_rules_and_timelines_status_route.ts
* x-pack/plugins/security_solution/server/lib/detection_engine/prebuilt_rules/logic/perform_timelines_installation.ts
### elastic/security-detections-response
* x-pack/test/security_solution_cypress/cypress/objects/timeline.ts
### elastic/security-engineering-productivity
* x-pack/test/security_solution_cypress/cypress/objects/timeline.ts
* x-pack/test/security_solution_cypress/cypress/tasks/api_calls/timelines.ts
```
### 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 <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
Modify code owner declarations for
`x-pack/test/functional/es_archives/canvas/logstash_lens` in
.github/CODEOWNERS
### For reviewers
To verify this pr, you can use the `scripts/get_owners_for_file.js`
script
E.g:
```
node scripts/get_owners_for_file.js --file x-pack/test/functional/es_archives/canvas/logstash_lens # Or any other file
```
#### Notes
All of these are a best guess effort. The more help from the dev teams,
the more accurate this will be for reporting in the future.
Contributes to: https://github.com/elastic/kibana/issues/192979
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
To only run when the label is removed and a backport:* label exists.
The on-merge workflow has historically supported version labels without
the existence of backport labels when a pull request is closed.
This isn't an expected use case now that we've enforced the label check,
but it still is possible to trigger.
Testing
1) Merge pull request
2) Add v8.16.0 , backport:skip labels
3) Remove backport:skip label (current trigger 1)
4) Add backport:prev-minor label (current trigger 2)
Should trigger the action once via step 4.
This PR is split into two commits, the first with the condition and the
second with the changes run through a formatter.
## Summary
Modify code owner declarations for @elastic/security-detection-engine
team in `.github/CODEOWNERS`
### Update for Reviewers
With the merge of [this](https://github.com/elastic/kibana/pull/193277),
you can now do this:
`node scripts/get_owners_for_file.js --file
x-pack/test/functional/es_archives/asset_criticality`
```
succ elastic/security-detection-engine
```
_So, you can use this script to see if the code owners file is reporting
erroneously_
### Only one un-contested change:
1. `/x-pack/test/functional/es_archives/asset_criticality
@elastic/security-detection-engine`
### Note
Oringinally I included
`/x-pack/test/functional/es_archives/security_solution
@elastic/security-detection-engine` but this was contested.
We will circle back around to this.
Contributes to: https://github.com/elastic/kibana/issues/192979
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
Closes#194051
As far as I can tell from the docs the `unlabeled` event sends
information about the removed label. I'm not sure the best way to test
this aside from merging the PR and adjusting the labels on this PR
afterwards. Reverting if needed.
Plan:
1. Merge PR
2. Add `backport:prev-minor`
3. Verify the workflow ran and _did not_ trigger a backport since
`backport:skip` is still a label
4. Remove `backport:skip`
5. Verify the workflow ran and _did_ trigger a backport to `8.x`
6. Revert the labels and close the backport PR since it is not actually
needed.
As best I can tell this was default assigned to operations during a
large refactor - https://github.com/elastic/kibana/pull/138965.
Operations is mostly disconnected from the UI. I'm proposing
transferring this over to area teams where flot is in use - stack
monitoring, canvas, and timelion.
## Summary
Part of #159917.
Moves code from `plugins/ml/common|public` to packages that is used by
transforms too.
While the transforms plugin is maintained by the ML team too, the
transform plugin itself is independently available from the ML UI in the
Kibana management section. We should try to avoid that the transform
plugin is directly depending on the `ml` plugin. This PR moves some code
from `plugins/ml/common|public` to packages so that we can remove `ml`
from the list of `requiredBundles` of the `transform` plugin.
The packages were created with these commands:
```
node scripts/generate package @kbn/ml-field-stats-flyout --dir ./x-pack/packages/ml/field_stats_flyout
node scripts/generate package @kbn/ml-parse-interval --dir ./x-pack/packages/ml/parse_interval
node scripts/generate package @kbn/ml-validators --dir ./x-pack/packages/ml/validators
```
The following commands were used to check missing jsdoc comments and
exports:
```
node scripts/build_api_docs --plugin @kbn/ml-field-stats-flyout --stats comments
node scripts/build_api_docs --plugin @kbn/ml-field-stats-flyout --stats exports
node scripts/build_api_docs --plugin @kbn/ml-parse-interval --stats comments
node scripts/build_api_docs --plugin @kbn/ml-parse-interval --stats exports
node scripts/build_api_docs --plugin @kbn/ml-validators --stats comments
node scripts/build_api_docs --plugin @kbn/ml-validators --stats exports
```
### 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
- [ ] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
- [x] This was checked for breaking API changes and was [labeled
appropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
## Summary
Renames the text-based-editor to esql-editor
I tried to also rename components, data-test-subj, classNames and files.
My focus is mostly on the plugin and package of the esql editor
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Modify code owner declarations for @elastic/response-ops team in
`.github/CODEOWNERS`
### Update for Reviewers
With the merge of [this](https://github.com/elastic/kibana/pull/193277),
you can now do this:
`node scripts/get_owners_for_file.js --file
x-pack/test/functional/es_archives/action_task_params`
```
succ elastic/response-ops
```
_So, you can use this script to see if the code owners file is reporting
erroneously_
### For Reviewers
Added these lines:
```
/x-pack/test/functional/es_archives/actions @elastic/response-ops
/x-pack/test/functional/es_archives/alerting @elastic/response-ops
/x-pack/test/functional/es_archives/alerts @elastic/response-ops
/x-pack/test/functional/es_archives/alerts_legacy @elastic/response-ops
/x-pack/test/functional/es_archives/observability/alerts @elastic/response-ops
/x-pack/test/functional/es_archives/actions @elastic/response-ops
/x-pack/test/functional/es_archives/rules_scheduled_task_id @elastic/response-ops
/x-pack/test/functional/es_archives/alerting/8_2_0 @elastic/response-ops
```
Most of these changes come from searching for `esArchiver.load`, within
`x-pack/test/alerting_api_integration`
Obviously this can easily be erroneous, so please keep me honest.
#### Notes
This is a best guess effort, as we march towards having zero files
within `test` && `x-pack/test` && `x-pack/test_serverless` without a
code owner.
In the end, this will contribute to better reporting.
Contribues to: https://github.com/elastic/kibana/issues/192979
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
The initial serverless only plugin for viewing data usage and retention
in Management. The purpose of this PR is to provide a place for other
engineers to work on it, hidden from public use.
- Plugin is hidden by default and can be enabled through kibana.yml
`xpack.dataUsage.enabled: true`
- Currently it will show up in both stateful and serverless (if enabled
using config above). When we are ready to make the plugin available we
will enable it in config/serverless.yml
- Renders a card in Management (serverless) when enabled:
<img width="1269" alt="Screenshot 2024-09-19 at 4 14 15 PM"
src="https://github.com/user-attachments/assets/705e3866-bc88-436a-8532-2af53167f7b1">
https://github.com/elastic/kibana/issues/192965https://github.com/elastic/kibana/issues/192966
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
In preparation for the GitHub team's renaming, it's required to update
this team in the codeowners file too.
This PR is dedicated to renaming @elastic/ent-search-design team to the
@elastic/search-design team
## Summary
The legacy `@elastic/kibana-gis` team is now a part of
`@elastic/kibana-presentation`. So we should move ownership of all code
to the correct team.
## Summary
Moving the Entity Manager out of Observability and into a Kibana plugin
as per [this
ticket](https://github.com/elastic/security-team/issues/10156)
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
We have to extract few components from `index_management` plugin to
shared packages for onboarding project. These extracted files would be
separated into small subject matter packages within a common folder -
`index-management` in `x-pack/packages/`.
What is covered in this PR?
* Created new folder `index-management` under [
x-pack/packages/](https://github.com/elastic/kibana/tree/main/x-pack/packages)
as a home for subject matter packages.
* moved existing package -
[@kbn/index-management](https://github.com/elastic/kibana/tree/main/x-pack/packages/index-management)
under `x-pack/packages/index-management`
* update name of
[@kbn/index-management](https://github.com/elastic/kibana/tree/main/x-pack/packages/index-management)
to `@kbn/index-management-shared-types`
* updated related files which use `@kbn/index-management` to use
`@kbn/index-management-shared-types`
**Note**
Extracting components required for onboarding project will be part of
another PR
## Description
This PR adds an inventory plugin, which renders an inventory UI.
Currently only data streams are rendered. This is part of the LogsAI
initiative - basically we need a UI for tasks like structuring data,
extracting entities, listing the results etc. This is mostly POC-level
stuff. Eventually some of this code might be handed over to ECO but
let's cross that bridge when we get to it.
## Notes for reviewers:
@elastic/appex-ai-infra @elastic/security-generative-ai: added a
`truncateList` utility function that takes the first n elements of an
array and appends a `{l-n} more` string value if there are more values
than n. Really simple but I expect will also be very often used because
we cannot send a huge amount of items to the LLM.
@elastic/kibana-core @elastic/kibana-operations: just boiler plate stuff
for adding a new plugin (and thank you for enabling us to run
`quick_checks` locally!
@elastic/obs-knowledge-team: added support for streaming using an
Observable.
@elastic/obs-ux-management-team: added links to the Inventory UI in the
Observability plugin
@elastic/obs-entities: I've added an entity manager client to be able to
fetch entity definitions on the server. Maybe there's a better way? LMK.
@elastic/obs-ux-logs-team: added a deeplink to the Inventory UI. I've
also moved CODEOWNERS for this package to
@elastic/obs-ux-management-team as they own the Observability plugin
where this is mostly used.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
**Relates to:** https://github.com/elastic/kibana/issues/190035
## Summary
This PR sets proper teams ownership to Security Solution OpenAPI domain
bundles. It will help to avoid unnecessary code review dependencies and
allow teams to focus on OpenAPI domain changes.
## UPDATE
It has been removed the execution of the playwright tests on buildkite,
the execution will be re-enabled as soon as we are ready and as
described below in the PR, there are still steps pending to be done.
## Motivation
**Cypress is not performing well lately.**
* We have been facing significant performance issues with Cypress. For
instance, it takes a long time to open the visual interface and start
executing tests.
**Teams are finding it increasingly challenging to write new tests and
debug existing ones.**
* The time and effort required to create new tests or troubleshoot
existing ones have become burdensome.
**Concern about the impact this could have on our testing practices.**
* Lose motivation to write tests or, worse, skip writing crucial tests.
## Why Playwright?
* Compared to Cypress, Playwright seems to be known for its faster
execution times and lower resource consumption. What could have a
positive impact by having faster feedback during development and
execution of new tests as well as more efficient use of CI resources.
* Provides powerful debugging tools which can make easier to write,
debug and execute tests.
* Seems to provide the same capabilities we currently use in our Cypress
tests.
* Given Playwright's active development and backing by Microsoft, it is
likely to continue evolving rapidly, making it a safe long-term choice.
Considering all the above, Playwright seems to be a strong candidate to
replace Cypress and address all the issues we are facing lately
regarding UI test automation.
## Objective of this POC
To write in Playwright a couple of tests we currently have on Cypress to
check the performance of the tool as well as the development experience.
The tests selected have been:
-
[enable_risk_score_redirect.cy.ts](https://github.com/elastic/kibana/blob/main/x-pack/test/security_solution_cypress/cypress/e2e/entity_analytics/dashboards/enable_risk_score_redirect.cy.ts)
- Owned by Entity Analytics team and selected by its simplicity since it
does not need any special setup to be executed and is short.
-
[manual_rule_run.cy.ts](https://github.com/elastic/kibana/blob/main/x-pack/test/security_solution_cypress/cypress/e2e/detection_response/detection_engine/rule_gaps/manual_rule_run.cy.ts)
- Owned by Detection Engine team and selected because is short and adds
a bit more of complexity due to it needs of clean-up and setting up
initial data through the API.
## How to execute the tests
### Visual mode
- Navigate to: `x-pack/test/security_solution_playwright`
- Execute: `yarn open:ess` for ESS environment or `yarn open:serverless`
for serverless environment.
### Headless mode
- Navigate to: `x-pack/test/security_solution_playwright`
- Execute: `yarn run:ess` for ESS environment or `yarn run:serverless`
for serverless environment.
### From VScode
- Install `Playwright Test for VScode` extension by Microsoft
- Navigate to: `x-pack/test/security_solution_playwright`
- Execute: `yarn open:ess` for ESS environment or `yarn open:serverless`
for serverless environment.
- Open your IDE
- Click on the `Testing` icon
- On the `Test Explorer` click on the three dots to select the profile
you are going to execute `ess` or `serverless`
- Click on the test you want to execute or navigate to the spec file of
the test and execute it from the same spec.
## My experience
- Tests are way easier to implement than with Cypress.
- Playwright does not rely on chainable commands. Chainable commands on
Cypress can lead to confusing code.
- Without chainable commands, the flow of the tests is more explicit and
easier to understand.
- You can notice that the tool has been designed with Typescript in
mind.
- Is super easy to implement the Page Object Model pattern (POM).
- With POM the test code is clean and focused on "what" rather than
"how".
- Love the fact that you can execute the tests from the same IDE without
having to switch windows during test development.
- The visual mode execution gives you lots of information out of the
box.
## The scope of this PR
- Sets the initial infrastructure to write and execute tests with
Playwright.
- Has examples and set a basis about how to write tests using the POM.
- Allows the execution of the tests in ESS and serverless (just
stateless environment).
- Integrates the execution of the tests with buildkite.
## Pending to be done/investigate
- Proper readme
- How to split tests and PO between the different teams
- Good reports on CI
- Upload screenshots on CI
- Flaky test suite runner
- Complete the labeling
- Execution of the tests on MKI environments
## FAQ
**Can I start adding tests to playwright?**
Currently, you can explore and experiment with Playwright, but there is
still work pending to be done to make the tool officially usable.
**Why security engineering productivity is the owner of the playwright
folder?**
This is something temporary to make sure that good practices are
followed.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: dkirchan <diamantis.kirchantzoglou@elastic.co>
Co-authored-by: Aleh Zasypkin <aleh.zasypkin@gmail.com>
Co-authored-by: Jon <jon@budzenski.me>
This workflow currently checkouts out two separate branches, but uses
the default branch as a reference when analyzing. We want the results to
split by the branch.
See https://github.com/github/codeql-action/blob/main/analyze/action.yml
for a description of supported options.
The previous https://github.com/elastic/kibana/pull/190105 was way too
big and made it hard to review without missing any bugs or potential
bugs, Thus we decided we are going to make series of smaller PR to make
things more manageable
We will be splitting it into 4 PR
Phase 1: Creating empty packages for csp and csp-common
Phase 2: Move Types from CSP plugin to the Package + Deleting duplicates
in the CSP plugin where possible
Phase 3: Move Functions, Utils or Helpers, Hooks to Package
Phase 4: Misconfiguration Preview feature (with Cypress test and other
required test)
<img width="681" alt="353329193-5ad22c4e-81c2-4a8b-89f7-fdbc2a686c2d"
src="https://github.com/user-attachments/assets/b369625a-efc5-4292-a690-2c5dffb5483d">
This is Phase 4 of the Process,
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Added bootstrap step before CodeQL scan.
Tested the run on push -
2942236822.
The workflow run was successful and had almost the same timing. Although
no new issues were identified, it's safe to keep the bootstrap step
before the scan.
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
Add the `gemini` model adapter for the `inference` plugin. Had to
perform minor changes on the associated connector
Also update the codeowner files to add the `@elastic/appex-ai-infra`
team as (one of the) owner of the genAI connectors
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Adds a `@kbn/observability-utils` package.
```md
# @kbn/observability-utils
This package contains utilities for Observability plugins. It's a separate package
to get out of dependency hell. You can put anything in here that is stateless and
has no dependency on other plugins (either directly or via other packages).
The utility functions should be used via direct imports to minimize impact on
bundle size and limit the risk on importing browser code to the server and vice versa.
```
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
