## Summary
This PR discontinues Reporting from having dual models for determining
the privilege to generate a report, and uses Kibana feature privileges
as the single model that controls those privileges.
### Changes
1. Removes all logic that is based on following settings:
* `xpack.reporting.roles.enabled`
* `xpack.reporting.roles.allow`
The settings are still supported, but any features that use the settings
are removed.
2. Removes the detection of the settings from the Upgrade Assistant
integration
### Release note
The default system of granting users the privilege to generate reports
has changed. Rather than assigning users the `reporting_user` role,
administrators should create a custom role that grants report-creation
privileges using Kibana application privileges.
### 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
- [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.
Correlates with https://elasticco.atlassian.net/browse/ES-9856: assign
the built-in `reporting_user` role the necessary Kibana application
privileges, and make the role not marked as deprecated.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Part of https://github.com/elastic/kibana-team/issues/1271
This PR introduces the first set of end to end integration test for the
inference APIs, and the tooling required to do so (see issue for more
context)
- Add a dedicated pipeline for ai-infra GenAI tests. pipeline is
triggered when:
- genAI stack connectors, or ai-infra owned code is changed
- when the `ci:all-gen-ai-suites` label is present on a PR
- on merge
- adapt the `ftr_configs.sh` script to load GenAI connector
configuration from vault when a specific var env is set
- create the `@kbn/gen-ai-functional-testing` package, which for now
only contains utilities to load the GenAI connector configuration in FTR
tests
- Add FTR integration tests for the `chatComplete` API of the
`inference` plugin
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This PR adds a baseline for FTR API tests for Automatic Import.
- Relates https://github.com/elastic/kibana/issues/196063
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
**Resolves: https://github.com/elastic/kibana/issues/201632**
## Summary
When the rule customization feature flag is disabled, we should always
return `isCustomized: false`, regardless of any changes introduced to a
rule. This ensures that we do not accidentally mark prebuilt rules as
customized in 8.16 with the feature flag off. For more details, refer to
the related issue: https://github.com/elastic/kibana/issues/201632
### Main Changes
- The primary change in this PR is encapsulated in the
`calculateIsCustomized` function
- Other changes involve passing the feature flag to this function
- Added integration tests to cover all API CRUD operations that can be
performed with rules
- Closes https://github.com/elastic/kibana/issues/167582
## Summary
This PR removes the code related to the legacy doc table and 2 Advanced
Settings: `doc_table:legacy` and `truncate:maxHeight`.
The legacy table in Discover was replaced by the new data grid in v8.3.
The `doc_table:legacy` Advanced Setting was added to let users switch
back to the legacy table if necessary. The removal of the setting and
the legacy table entirely would allow us to reduce bundle size,
maintenance burden, and code complexity.
Also the legacy table does not support many new features which were
added to the grid only (e.g. comparing selected documents, context-aware
UI based on current solution project, column resizing, bulk row
selection, copy actions, new doc viewer flyout, and more).
Since v8.15 `doc_table:legacy` is marked as deprecated on Advanced
Settings page via https://github.com/elastic/kibana/issues/179899
Since v8.16 `truncate:maxHeight` is marked as deprecated too via
https://github.com/elastic/kibana/pull/183736
The removal of these 2 settings and the associated code is planned for
v9.
### 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
Add quick check to prevent test files from being added without an owner
Resolves: #192979
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: Robert Oskamp <robert.oskamp@elastic.co>
The number of steps in pull request builds has been causing GitHub API
rate limit issues. In particular, scenarios that cause all steps to fail
have proven to quickly trigger the rate limit.
The disables step statuses on pull requests. We will still have our
required kibana-ci check for the overall build, and the pull request
comment can be used as the source of individual step failures.
Defines disk size for artifact builds. This will be a no-op - the boot
disk size is >= the definitions in this PR.
A test run with the smaller boot disk can be seen in
https://buildkite.com/elastic/kibana-pull-request/builds/248242. I plan
on making further adjustments after the boot disk has been promoted.
## Summary
This PR introduces the first integration test for the Streams project.
This test covers the following basic functionality:
- Enable streams
- Index a document to `logs`
- Create a `logs.nginx` for that reroutes based on `log.logger ==
'nginx'`
- Index a document to `logs.nginx`
- Create a `logs.nginx.access` that reroutes based on `log.level ==
'info'`
- Index a document to `log.nginx.access`
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: Joe Reuter <johannes.reuter@elastic.co>
## Summary
This PR moves a couple of entries from
`.buildkite/ftr_security_stateful_configs.yml` to
`.buildkite/ftr_security_serverless_configs.yml` as they seemed to be
related to serverless.
## Summary
Part of #199182
With great progress of #193245 the number of tests in Observability
deployment-agnostic config files is growing and so does config run time
by reaching **30** minutes.
As we try to keep pipeline runtime reasonable, this PR adds a new
configs `oblt.apm.stateful.config.ts` and
`oblt.apm.serverless.config.ts` that load only APM-related tests from
https://github.com/elastic/kibana/blob/main/x-pack/test/api_integration/deployment_agnostic/apis/observability/apm/index.ts
It should help to speed up execution, we will double check config
runtime when APM test migration is completed.
For reviewers: no extra work is expected from Oblt teams if new tests
are still imported in
`x-pack/test/api_integration/deployment_agnostic/apis/observability/apm/index.ts`
## Summary
The solution must be aware of the onboarding token from the cloud
onboarding flow. With this information, it can redirect our users to the
appropriate onboarding flow in Kibana based on their token. We need to
create an API in kibana for cloud to save some basic data.
### 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: Christiane (Tina) Heiligers <christiane.heiligers@elastic.co>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Closes#192233
Just in time for Thanksgiving - a full buffet of FIPS testing fixes
Usage of non-compliant algorithms manifest as runtime errors, so it is
imperative that we attempt to run all tests possible with Kibana in FIPS
mode. However, several overrides are needed to run Kibana in FIPS mode,
resulting in setup that make it impossible to run.
## In this PR
- Enable Unit tests for FIPS pipeline
- Enable Integration Tests for FIPS pipeline
- Enable Full FTR suite for FIPS pipeline (smoke test had originally run
a subset)
- Skip tests that break with overrides
- Fix/change tests to work in FIPS mode to maximize coverage
- Examine necessity of MD5 when installing from source (TBD based Ops PR
feed back, see self review below)
- Remove md5 from es_file_client options
## Latest Successful FIPS Test Run
https://buildkite.com/elastic/kibana-fips/builds/268
---------
Co-authored-by: Brad White <Ikuni17@users.noreply.github.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Aleh Zasypkin <aleh.zasypkin@gmail.com>
Co-authored-by: Larry Gregory <larry.gregory@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>
## Fix the link for test command in the MKT tests
Just change tests to be similar what we have in periodic pipeline
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
The platform plugin builds were used when functional tests were, at
times, run from source.
This is mostly no longer a requirement. There are two remaining cypress
scripts that I updated to use the build instead.
With the time saved I'm dropping the number of vCPUs from 16 to 8. These
are mostly underutilized by this step, with the exception of the
distribution plugin build.
Currently pull request builds that create bundle changes over the limits
defined in `packages/kbn-optimizer/limits.yml` receive an error in the
`Post Build` step. This information is available earlier, after the
`Build Distribution` step.
By failing earlier we can reduce the number of test runs caused by
bundle limit changes. The report created in the `Post Build` step will
continue to behave as it currently is.
## Summary
Adds FTR tests that check our Serverless prebuilt roles against our
exception list endpoints.
We have had little coverage or visibility to know if any changes made in
elasticsearch-controller introduce a bug in our prebuilt roles.
We could certainly discuss how such tests should be organized - I chose
to create an `authentication` folder that then has a matching folder for
the other sections and a file for each prebuilt role. With us nearing
GA, I'd like to prioritize having coverage and following up with any
improvements.
Adds a placeholder pipeline for `kibana / package registry promote`.
Initially, in a follow up PR, this will run a daily promotion of
`docker.elastic.co/package-registry/distribution:lite` to the kibana-ci
namespace. We can also run some verification steps if desired.
The distribution is a relatively large image, and nearly always running
uncached on CI due to the update frequency. This should help us balance
having an up to date image and avoiding cache misses.
Currently CI is configuring a yarn local mirror that is ignored due to
the repository `.yarnrc` taking precedence.
Instead of configuring this setting, this moves the cached mirror over
to the Kibana directory in line with the repository's configuration.
Should be the last group to move before tests for now.
The intent has been to move steps that fit in the build window to run
before tests start. Catching errors before parallel steps should help
reduce the number of test runs with known issues.
