## Summary
Due to the much slower rate of versioning public APIs we have decided to
remove the Elastic-Api-Version body and header information from the spec
entirely.
This also cleans up the spec when rendered on our hosted OAS docs.
Removes:
1. `Elastic-Api-Version` from the request/response bodies for all public
APIs
2. `Elastic-Api-Version` header parameter from all public APIs
Docs for internal APIs will still have this included as they always
require a version environments.
## To revewers
Important changes are all in `packages/kbn-router-to-openapispec` and
`src/core/server/integration_tests/http/oas.test.ts`, the rest is very
minor or generated/snapshotted changes.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Fix a few issues encountered with schema validation.
One of them reported here:
https://discuss.elastic.co/t/fleet-error-updating-policy-settings/371332
The other encountered locally when testing upgrades:
```
"Failed output validation: [request body.items.0.upgrade_details]: expected a plain object value, but found [null] instead."
```
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
This PR contains the following updates:
| Package | Type | Update | Change | Pending |
|---|---|---|---|---|
| [@redocly/cli](https://togithub.com/Redocly/redocly-cli) |
devDependencies | patch | [`^1.25.13` ->
`^1.25.14`](https://renovatebot.com/diffs/npm/@redocly%2fcli/1.25.14/1.25.14)
| `1.25.15` |
| [@redocly/cli](https://togithub.com/Redocly/redocly-cli) |
dependencies | patch | [`^1.25.13` ->
`^1.25.14`](https://renovatebot.com/diffs/npm/@redocly%2fcli/1.25.14/1.25.14)
| `1.25.15` |
---
### Configuration
📅 **Schedule**: Branch creation - At any time (no schedule defined),
Automerge - At any time (no schedule defined).
🚦 **Automerge**: Disabled by config. Please merge this manually once you
are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the
rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about these
updates again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box
---
This PR has been generated by [Renovate
Bot](https://togithub.com/renovatebot/renovate).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzNy40MjUuMSIsInVwZGF0ZWRJblZlciI6IjM3LjQyNS4xIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6WyJUZWFtOkNvcmUiLCJiYWNrcG9ydDphbGwtb3BlbiIsInJlbGVhc2Vfbm90ZTpza2lwIl19-->
Co-authored-by: elastic-renovate-prod[bot] <174716857+elastic-renovate-prod[bot]@users.noreply.github.com>
## Summary
resolves https://github.com/elastic/kibana/issues/159454
Remove experimental message from saved objects import and export apis.
### Checklist
Check the PR satisfies following conditions.
Reviewers should verify this PR satisfies this list as well.
- [x]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
### Identify risks
Does this PR introduce any risks? For example, consider risks like hard
to test bugs, performance regression, potential of data loss.
Describe the risk, its severity, and mitigation for each identified
risk. Invite stakeholders and evaluate how to proceed before merging.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
* Add two tabs to the Entity Store page
* The import entities tab has all the bulk upload content
* The status tab has the new content created on this PR
* Move the "clear entity store data" button to the header according to
design mockups.
* Delete unused stats route
* Rename `enablement` API docs to `enable`
* Add a new parameter to the status API (`withComponents`)
* Should I make it snake cased?
### import entities tab
### status tab
## How to test it
- Open security solution app with data
- Go to entity store page
- You shouldn't see the new tab because the engine is disabled
- Enable the engine and wait
- Click on the new tab that showed up
- It should list user and host engine components, and everything should
be installed
- Delete or misconfigure some of the resources, the new status should be
reflected on the tab.
## TODO:
- [x] Rebase main after https://github.com/elastic/kibana/pull/199762 is
merged
- [x] Remove temporary status hook
- [x] Fix the"clear entity data" button. It should re-fetch the status
API.
### Checklist
Reviewers should verify this PR satisfies this list as well.
- [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: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
This PR contains the following updates:
| Package | Type | Update | Change | Pending |
|---|---|---|---|---|
| [@redocly/cli](https://togithub.com/Redocly/redocly-cli) |
devDependencies | patch | [`^1.25.12` ->
`^1.25.13`](https://renovatebot.com/diffs/npm/@redocly%2fcli/1.25.14/1.25.13)
| `1.25.14` |
| [@redocly/cli](https://togithub.com/Redocly/redocly-cli) |
dependencies | patch | [`^1.25.12` ->
`^1.25.13`](https://renovatebot.com/diffs/npm/@redocly%2fcli/1.25.14/1.25.13)
| `1.25.14` |
---
### Configuration
📅 **Schedule**: Branch creation - At any time (no schedule defined),
Automerge - At any time (no schedule defined).
🚦 **Automerge**: Disabled by config. Please merge this manually once you
are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the
rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about these
updates again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box
---
This PR has been generated by [Renovate
Bot](https://togithub.com/renovatebot/renovate).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzNy40MjUuMSIsInVwZGF0ZWRJblZlciI6IjM3LjQyNS4xIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6WyJUZWFtOkNvcmUiLCJiYWNrcG9ydDphbGwtb3BlbiIsInJlbGVhc2Vfbm90ZTpza2lwIl19-->
Co-authored-by: elastic-renovate-prod[bot] <174716857+elastic-renovate-prod[bot]@users.noreply.github.com>
Co-authored-by: Alejandro Fernández Haro <alejandro.haro@elastic.co>
## Summary
Resolves https://github.com/elastic/ingest-dev/issues/3933. For
deployments that support agentless, integrations with agentless
deployment mode enabled will allow the status of agentless integration
policies to be tracked.
### Key technical changes
- A new field `supports_agentless` was added to package policies. This
field already exists on agent policies. When an agentless integration is
created, `supports_agentless: true` is now added to both the package
policy and its parent agent policy.
- This allows easier filtering for agentless integrations as we avoid
having to retrieve & check against every parent agent policy.
- This also means existing agentless policies do not get this new status
tracking UI, only new ones created after this change. Since agentless is
not yet GA, I think this is okay.
- `/api/fleet/agent_status/data` now takes optional query params
`pkgName` and `pkgVersion`. When both are specified, the API will check
if agent(s) have ingested data for only that package's datastreams.
## UI walkthrough
<details>
<summary>🖼️ Click to show screenshots</summary>
1. **Integration policies** page now shows two tables for integrations
meeting the above condition, one for agentless policies and one for
agent-based policies:
2. Clicking the status badge in the agentless policies table opens a
flyout with two steps: confirm agentless enrollment and confirm incoming
data:
3. Confirm agentless enrollment polls for an agent enrolled into that
integration policy's agent policy. If that agent is reporting an
unhealthy status, the integration component UI is shown. This UI is the
same one used on Fleet > Agents > Agent details page and shows all
components reported by that agent:
4. Once a healthy agentless enrollment is established, confirm incoming
data starts polling for data for that integration ingested by that agent
ID in the past 5 minutes:
5. If data could not be retrieved in 5 minutes, an error message shows
while polling continues in the background:
6. If data is retrieved, a success message is shown:
</details>
## Testing
Easiest way to test is use the Cloud deployment from this PR. Enable
Beta integrations and navigate to CSPM. Add a CSPM integration using
`Agentless` setup technology. Then you can track the status of the
agentless deployment on the Integrations policies tab.
For local testing, the following is required to simulate agentless
agent:
1. Add the following to kibana.dev.yml:
```
xpack.cloud.id: 'anything-to-pass-cloud-validation-checks'
xpack.fleet.agentless.enabled: true
xpack.fleet.agentless.api.url: 'https://localhost:8443'
xpack.fleet.agentless.api.tls.certificate: './config/certs/ess-client.crt'
xpack.fleet.agentless.api.tls.key: './config/certs/ess-client.key'
xpack.fleet.agentless.api.tls.ca: './config/certs/ca.crt'
```
2. Apply [this
patch](https://gist.github.com/jen-huang/dfc3e02ceb63976ad54bd1f50c524cb4)
to prevent attempt to create agentless pod
3. Enroll a Fleet Server as usual
4. Enable Beta integrations and navigate to CSPM. Add a CSPM integration
using `Agentless` setup technology.
5. Enroll a normal Elastic Agent to the agent policy for that CSPM
integration by using the token from Enrollment tokens
## To-do
- [x] API tests
- [x] Unit UI tests
- [x] Manual Cloud tests
- [x] File docs request
- https://github.com/elastic/ingest-docs/issues/1466
- [ ] Update troubleshooting guide link once available
### Checklist
Delete any items that are not applicable to this PR.
- [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)
- [ ]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
- [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>
## Summary
Closes https://github.com/elastic/kibana/issues/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 <42973632+kibanamachine@users.noreply.github.com>
## Summary
The timeline API endpoints are currently implemented from a mix of HTTP
and GraphQL practices. Since GraphQL has been removed for a long time
now, we should make sure the endpoints conform to HTTP best practices.
This will allow us to simplify the API- and client-logic. Further,
third-parties accessing these APIs will have an easier time integrating.
### Usage of HTTP status codes
Depending on the error, the API endpoints currently return a `200` with
`{ code: 404, message: '(...)' }` or an actual HTTP error response with
e.g. `403` and the message in the body. The practice of returning 200s
with embedded error codes comes from GraphQL, where error codes are
always embedded.
Example of a current HTTP response of a failed timeline request:
```
HTTP status: 200
HTTP body:
{
"error_code": 409,
"messsage": "there was a conflict"
}
```
Going forward, all endpoints should return proper error codes and embed
the error messages in the response body.
```
HTTP status: 409
HTTP body:
{
"messsage": "there was a conflict"
}
```
### Removal of `{}` responses
Some timeline endpoints might return empty objects in case they were not
able to resolve/retrieve some SOs. The empty object implies a `404`
response. This creates complications on the client that now have to
provide extra logic for how to interpret empty objects.
Example of a current request of one of the endpoints that allows empty
responses.
```
HTTP status: 200
{}
```
The absence of an object, on some of the listed endpoints, indicates a
404 or the top-level or embedded saved object.
Going forward, the endpoints should not return empty objects and instead
return the proper HTTP error code (e.g. `404`) or a success code.
```
HTTP status: 404
```
### No more nested bodies
Another relic of the GraphQL time is the nesting of request bodies like
this:
```
HTTP status: 200
HTTP body:
{
"data": {
"persistTimeline": {
(actual timeline object)
}
}
}
```
Combined with sometimes returning empty objects and potentially
returning a status code in the body, makes it overly complicated for
clients to reason about the response.
Going forward, the actual object(s) should be returned as a top-level
JSON object, omitting `data.persistX`.
```
HTTP status: 200
HTTP body:
{
(actual timeline object)
}
```
### Checklist
- [x]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
- [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] This was checked for breaking HTTP API changes, and any breaking
changes have been approved by the breaking-change committee. The
`release_note:breaking` label should be applied in these situations.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
This PR adds 2 new endpoints regarding enablement of the Entity Store:
* `api/entity_store/enable`, which initializes entity engines for both
`user` and `host` entities
* `api/entity_store/status`, which computes a global store status based
on the individual engine status
In addition, running initialization of multiple engines in parallel is
now allowed.
### How to test
1. Use dev tools to call `POST kbn:/api/entity_store/enable`
2. Check that two engines were created and that the status is
`installing` by calling `GET kbn:/api/entity_store/status`
3. Wait a few seconds and keep calling the `status` endpoint. Once
initialization finishes, the status should switch to `running`
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Fixes#22832
## Summary
This PR adds the possibility of adding Files/Attachments to Case in
Kibana via an API call.
### How to test
The new API URL is `https://localhost:5601/api/cases/<CASE_ID>/files`.
You can either use postman or curl to test.
1. Start by creating a case.
2. Call the new API
```
curl --location 'https://localhost:5601/api/cases/<CASE_ID>/files' \
--header 'kbn-xsrf: true' \
--header 'Authorization: Basic ZWxhc3RpYzpjaGFuZ2VtZQ==' \
--form 'filename="Notice"' \
--form 'mimeType="text/plain"' \
--form 'file=@"<FULL_PATH_TO_THE_FILE_YOU_WANT_TO_UPLOAD>"'
```
<img width="1090" alt="Screenshot 2024-10-30 at 15 41 26"
src="https://github.com/user-attachments/assets/b018f92d-2603-4bf1-ac12-f01452f35303">
3. Confirm the user action was created.
<img width="383" alt="Screenshot 2024-10-30 at 15 48 45"
src="https://github.com/user-attachments/assets/04952b8f-e8fb-4f19-a72f-54030f496fe9">
4. Confirm the file exists in the case and:
- it can be downloaded as expected.
- it can be previewed as expected(not every MIME type allows this).
### Release Notes
Files can now be attached to cases directly via API.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: lcawl <lcawley@elastic.co>
## Summary
Publish OAS docs to bump.sh on merge to `main` or `8.x`
## To reviewers
* For now actual publication requires a manual step on bump.sh (so
things aren't going live immediately)
* Will get to serverless OAS docs next!
## Blockers
* Address vulnerable deps before merging:
https://github.com/bump-sh/cli/issues/583
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Updates the Open API docs make targets to use the correct bump.sh
dependency.
Unless I'm missing something obvious in my local configuration, `@npx
bump ...` uses [node-bump](https://www.npmjs.com/package/bump) not the
[bump.sh library](https://www.npmjs.com/package/bump-cli). I discovered
this while trying to run the make targets locally.
## Summary
- This adds api removals for deprecated API's.
- Also updates OAS documentations and api types.
- Also updates/removes test.
These changes are intended to be for `9.0` and Serverless GA.
API's removed:
- `/api/endpoint/isolate`
- `/api/endpoint/unisolate`
- `/api/endpoint/policy/summaries`
- `/api/endpoint/suggestions/{suggestion_type}`
- `/api/endpoint/action_log/{agent_id}`
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
**Partially addresses:** https://github.com/elastic/kibana/issues/171520
## Summary
This PR adds is built on top of https://github.com/elastic/kibana/pull/193828 and https://github.com/elastic/kibana/pull/196948 and adds an Alert Suppression editable component for Three Way Diff tab's final edit side of the upgrade prebuilt rule workflow.
## Details
https://github.com/elastic/kibana/issues/171520 required adding editable components for each field diffable rule field. Alert Suppression edit component was extracted from Define Rule Step Component into a separate reusable component. To simplify the logic it was split into common Alert Suppression and Threshold Alert Suppression since the latter is a specific use case.
## Caveats
Upgrade prebuilt rules workflow is quite different from rule creation and editing. In create and edit rule forms users are capable to change any field at their will. Upgrade prebuilt rules workflow allow to modify only specific fields having diff in the current rule upgrade.
There are fields which depend on each other. In particular Alert Suppression isn't supported for EQL sequence though it's addressed in https://github.com/elastic/kibana/pull/189725.
- Alert Suppression editable component in Three Way Diff workflow isn't disabled EQL sequence rule queries. Alert suppression support for rules with EQL sequence queries is implemented in https://github.com/elastic/kibana/pull/189725.
- Machine learning rule type require running selected machine learning jobs otherwise input could be disabled in case of there are no fields to pick from otherwise a warning message below the combobox is shown.
## How to test
The simplest way to test is via patching installed prebuilt rules via Rule Patch API. Please follow steps below
- Enable Prebuilt rule customization feature by adding a `prebuiltRulesCustomizationEnabled` feature flag
- Run Kibana locally
- Install a prebuilt rule, e.g. `Potential Code Execution via Postgresql` with rule_id `2a692072-d78d-42f3-a48a-775677d79c4e`
- Patch the installed rule by running a query below
```bash
curl -X PATCH --user elastic:changeme -H 'Content-Type: application/json' -H 'kbn-xsrf: 123' -H "elastic-api-version: 2023-10-31" -d '{"rule_id":"2a692072-d78d-42f3-a48a-775677d79c4e","version":1,"alert_suppression":{"group_by":["host.name"]}}' http://localhost:5601/kbn/api/detection_engine/rules
```
- Open `Detection Rules (SIEM)` Page -> `Rule Updates` -> click on `Potential Code Execution via Postgresql` rule -> expand `EQL Query` to see EQL Query -> press `Edit` button
## Screenshots
Custom query prebuilt rule (UI looks similar for EQL, Indicator Match, New Terms and ES|QL rule types)
Machine learning prebuilt rule with a diff in alert suppression
Threshold prebuilt rule
fix https://github.com/elastic/kibana/issues/197721.
The route deprecation field changed from a boolean to an object, where
the object contains information that is used in deprecation issues that
the Upgrade Assistant shows.
This PR makes the necessary changes in the deprecated Saved Objects HTTP
APIs.
This PR also includes a release notes entry for the API deprecations
that was missing.
### 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]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
- [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
### How to test this:
- Pull PR, run es against a trial license and start kibana as usual.
- Make a curl request to Kibana to get the config saved object:
```
curl --location 'localhost:5601/abc/api/saved_objects/config/9.0.0' \
--header 'Content-Type: application/json' \
--header 'Accept-Encoding: gzip, deflate, br' \
--header 'kbn-xsrf: kibana' \
--header 'Kbn-Version: 9.0.0' \
--header 'Authorization: Basic ZWxhc3RpYzpjaGFuZ2VtZQ=='
```
- Navigate to Upgrade Assistant and observe Kibana has at least 1
deprecation warning.
- View Kibana's warnings, you should see a warning entry for `The "GET
/api/saved_objects/{type}/{id}" route is deprecated`
- click on the deprecation and you should see more detail about the
deprecated API that's been used in the flyout:
- resolve the deprecation warning
- Kibana should continue to issue requests to the deprecated SO HTTP
APIs because these APIs have not been removed yet.
### Risk Matrix
| Risk | Probability | Severity | Mitigation/Notes |
|---------------------------|-------------|----------|-------------------------|
| End user concern from the deprecation warning that says the routes
have been deprecated | Low | Low | The APIs have been deprecated since
8.7 and recommends using public APIs instead. |
### For maintainers
- [x] This will appear in the **Release Notes** and follow the
[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Resolves https://github.com/elastic/kibana/issues/90382
## Summary
Removes legacy action APIs for 9.0 and updates all tests that still used
the legacy APIs to use the current APIs. Also did some renaming of
action -> connector in the files I had to touch.
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Towards: #172513
This PR removes `RawRule` type from `alerting/server/type` and
`RuleAttributes` schema/types.
And uses the `RawRule` that is used for ModelVersions instead of them.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
**Epic:** https://github.com/elastic/security-team/issues/9401 (internal)
## Summary
This PR adds Kibana OpenAPI bundling documentation. The functionality includes multiple scripts and automation scattered throughout the vast Kibana repo. The goal is to document the whole chain and make it transparent for the readers.
## Summary
Removing staging files for now. We can always revert this if it turns
out we need them.
## Reviewers
* I might be missing something in removing these, but right now I think
they are making commit noise and not really serving a purpose
* I moved the `final_merge` step to after the OAS snapshot capture
