## Summary
This PR adds a test config category to the scout reporting. This allows
us to distinguish between UI and API FTR tests.
A new property `testConfigCategory` has been added to all FTR configs
that don't already inherit it from a higher level config.
Closes#194933Closes#192282
## Summary
This PR updates the serverless project yml files to
- enable custom roles for Elasticsearch and Security projects
- enable multiple spaces (max 100) for all serverless project types
### Tests
Additionally, this PR adjust the serverless test suites. Originally,
testing of roles and spaces endpoints was achieved from the feature flag
test config. Now that these features are enabled by default, the tests
have been migrated to the standard serverless test configs.
Affected tests:
-
x-pack/test_serverless/api_integration/test_suites/common/management/spaces.ts
-
x-pack/test_serverless/api_integration/test_suites/common/platform_security/authorization.ts
-
x-pack/test_serverless/functional/test_suites/common/platform_security/navigation/management_nav_cards.ts
-
x-pack/test_serverless/functional/test_suites/common/platform_security/roles.ts
-
x-pack/test_serverless/functional/test_suites/common/spaces/spaces_management.ts
-
x-pack/test_serverless/functional/test_suites/common/spaces/spaces_selection.ts
- Feature flag configs/indices
- Project specific configs/indices
- Base serverless config
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Dzmitry Lemechko <dzmitry.lemechko@elastic.co>
## Summary
This PR updates FTR services to support authentication with custom
native role. Few notes:
- for compatibility with MKI we reserve **"customRole"** as a custom
role name used in tests
- test user is **automatically assigned** to this role, but before login
in browser/ generating cookie header or API key in each test suite
**role privileges must me updated according test scenario**
How to test:
I added a new test file for Search project:
`x-pack/test_serverless/functional/test_suites/search/custom_role_access.ts`
It can be run locally with:
```
node scripts/functional_tests --config=x-pack/test_serverless/functional/test_suites/search/config.ts --grep "With custom role"
```
FTR UI test example:
```ts
// First set privileges for custom role
await samlAuth.setCustomRole({
elasticsearch: {
indices: [{ names: ['logstash-*'], privileges: ['read', 'view_index_metadata'] }],
},
kibana: [
{
feature: {
discover: ['read'],
},
spaces: ['*'],
},
],
});
});
// Then you can login in browser as a user with newly defined privileges
await pageObjects.svlCommonPage.loginWithCustomRole();
```
FTR api_integration test example:
```ts
// First set privileges for custom role
await samlAuth.setCustomRole({
elasticsearch: {
indices: [{ names: ['logstash-*'], privileges: ['read', 'view_index_metadata'] }],
},
kibana: [
{
feature: {
discover: ['read'],
},
spaces: ['*'],
},
],
});
});
// Then you can generate an API key with newly defined privileges
const roleAuthc = await samlAuth.createM2mApiKeyWithRoleScope('customRole');
// Don't forget to invalidate the API key in the end
await samlAuth.invalidateM2mApiKeyWithRoleScope(roleAuthc);
```
## Summary
It seems beneficial to have feature flag tests in a separate test config
file
- tests are still run on Kibana CI automatically
- tests are not run on MKI projects automatically, but you can deploy
custom project and run tests via feature flags config
All the feature flags within the same project should be places in the
same config to make sure there is no arguments conflict.
When the flag is moved to the yml configuration, we can rely on Kibana
CI and manually triggered deployment to make sure projects are
functioning correctly.
---------
Co-authored-by: Robert Oskamp <robert.oskamp@elastic.co>
## Summary
fixes https://github.com/elastic/kibana/issues/160126
This PR
- hides owner selection while adding lens to case from dashboard for
observability and securitySolution serverless
- hides add to new case and add to existing case lens action for
Elasticsearch serverless
**How to test**
- Run Observability/Securtiy solution serverless project and add lens
visualization to case from dashboard
- Run ES serverless project and check that lens do not have option to
add to case
- Classic kibana works as before (check dashboard from securitySolution
and generic dashboard as well)
### Checklist
Delete any items that are not applicable to this PR.
- [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
### For maintainers
- [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)
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
It fixes#161458 by adding API integration tests for the Threshold rule,
with many scenarios (file per scenario), and each scenario has a
complete life-cycle
### The scenario life-cycle
- Generating data using the `fake_host` dataset from the high-card
- Create a DataView based on the generated data
- Create the rule and wait to be active
- Get the fired alert and matches its value
- Clean up
### The covered scenarios
- Avg. percentage, fires alert
- Avg. percentage, fires alert with no data
- Custom equation on bytes filed, fires alert
- Doc count, fires alert
- Group by two fields, fires alert.
---------
## Summary
This PR removes standalone `common` serverless tests and instead makes
them run as part of every serverless project's tests.
### Details
Before, the `common` tests ran on a "vanilla" Kibana serverless mode
(i.e. the `serverless` plugin was loaded but none of the
`serverless-PROJECT` plugins). With continued serverless development,
this state of Kibana doesn't work as expected anymore and since this is
not supported officially anyway, it's not worth to invest making it work
properly. So we decided to accept the extra test run time and actually
include `common` tests in every project.
Currently the common configurations run with an undefined project. In
development, this will select the most recent project run via
`serverless.recent.yml`, or default to `es`. On distributions, a project
must be selected.
This updates the test server arguments to run the base configuration
instead, where all projects are disabled but the app switcher and home
page is available.
This will be used for issue tracking and metrics. Reports will be output
to the `target/junit` folder.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This PR adds boilerplate code and a few initial end-to-end tests to
serverless plugins.
Note that the tests defined in this PR are not part of any CI run yet,
this will be done in a follow-up after this PR is merged.
### Details
The serverless test structure corresponds to what we have in
`x-pack/test` with API tests in `api_integration` and UI tests in
`functional`, each with their set of helper methods and sub-directories
for
- `common` functionality shared across serverless projects (core, shared
UX, ...)
- `observability` project specific functionality
- `search` project specific functionality
- `security` project specific functionality
The `shared` directory contains fixtures, services, ... that are shared
across `api_integration` abd `functional` tests.
```
x-pack/test_serverless/
├─ api_integration
│ ├─ services
│ ├─ test_suites
│ │ ├─ common
│ │ ├─ observability
│ │ ├─ search
│ │ ├─ security
├─ functional
│ ├─ page_objects
│ ├─ services
│ ├─ test_suites
│ │ ├─ common
│ │ ├─ observability
│ │ ├─ search
│ │ ├─ security
├─ shared
│ ├─ services
│ ├─ types
```
See also `x-pack/test_serverless/README.md`
### Run tests
Similar to how functional tests are run in `x-pack/test`, you can point
the functional tests server and test runner to config files in this
`x-pack/test_serverless` directory, e.g. from the `x-pack` directory
run:
```
node scripts/functional_tests_server.js --config test_serverless/api_integration/test_suites/common/config.ts
```
and
```
node scripts/functional_test_runner.js --config test_serverless/api_integration/test_suites/common/config.ts
```
### Additional changes
- The stateful `common_page` page object used the existence of the
global nav to determine `isChromeVisible` and `isChromeHidden`, which is
not working when the global nav is disabled. To solve this, a
`data-test-subj` that indicates the chrome visible state is added to the
Kibana app wrapper and is used for the checks.
- Add a few `data-test-subj` entries to the Observability overview page.
- Add optional `dataTestSubj` to the `Navigation` component and use that
for the serverless search nav.
- Add optional `titleDataTestSubj` to the `SolutionNav` component and
use it for the serverless security nav.
- Add a data-test-subj entry to the Search overview page.
