* [SR] Snapshot and restore plugin boilerplate (#32276)
* Initial plugin set up
* Set up client shell
* Add initial repository list routes
* Fix merge issues and some typings
* Decouple server from plugin.ts files, tighten up typings
* Use exported constant for required license
* Translate plugin name, more typings
* Fix more types, move list components under /home
* Remove unused var
* Change scss prefix
* Uncouple unmount logic from routing shim, and some other PR feedback
* [SR] Repository list and details UI (#33367)
* Initial pass at repositories list UI
* Add detail panel for file system repositories, and a generic detail panel with json settings view
* Add detail components for other types
* Add detail panel footer, rename `useStateValue` to `useAppState`
* Fix detail panel footer
* Fix unused vars
* PR feedback
* PR feedback
* [SR] Refactor proposal (#33690)
* Move app dependencies to its own context provider
* Add index.ts barrel file for common types
* Move Enums to constants.ts file
* Refactor function component using `React.FunctionComponent<Props>`
* Refactor service folder structure
* Fix type import
* Move REPOSITORY_DOC_PATHS from common to public constants
* Move AppCore and AppPlugins interfaces back to shim and re-export them from app types
* [SR] Create and edit repositories UI (#34020)
* Add routing and placeholder form
* Fix typings
* Set up edit repository route, and basic form UI
* Add typings for wrapCustomError, and copy extractCausedByChain from CCR wrapEsError
* Throw errors that are already boomified
* Create and edit for basic repository types (fs, url, source)
* Add repository verification UI to table and details
* Create and edit for plugin repository types (hdfs, azure, s3, gcs)
* Fix linting
* Fix test
* Fix test
* Remove unused import
* Fix duplicate i18n key
* Fix details opening on cancel edit, remove unnecessary Fragments, definition file for some EUI components to x-pack, rename saveError
* Remove breaks
* Adjust add and edit repo routes so they don't conflict with list route
* Add repo plugin and types doc links to form
* Bootstrap documentation service
* Bootstrap text service and replace RepositoryTypeName component with it
* Bootstrap breadcrumb service and replace usages
* Bootstrap httpService, remove chrome and http from app dependencies(!)
* Add request creator and replace all instances of useRequest and sendRequest with it
* Fix typo
* Simplify update repository and update repository setting methods
* Adjust copy
* Lint
* Remove unused var
* Remove unused import
* [SR] Add API for retrieving snapshots. (#34598)
* [SR] Single and multiple repository delete (#34593)
* Add single/multi repository delete API and UI
* Address PR feedback
* [SR] Add SnapshotTable and SnapshotDetails. (#34837)
* Remove associations between multiple repositories with a single snapshot.
* Retrieve complete snapshot details in getAllHandler.
* Fix cleanup function bug in useRequest hook.
* Fix bug in useRequest which prevented old data from being cleared when subsequent requests returned errors.
* Add initialValue config option to useRequest.
* Add formatDate service to text module.
* [SR] Fix linting and add (de)serialization for repositories (#35031)
* Fix eslint issues and add (de)serialization for repositories
* Add comment about flattening settings
* [SR] Surface repository errors and index failures more prominently (#35042)
* Add links to repositories from Snapshot Table and Snapshot Details.
- Rename services/breadcrumbs to services/navigation and add linkToRepository function.
- Refactor home component to update active tab when URL was changed.
* Add warning callout to let user know when their repositories contain errors.
* Sort failures by shard and add test for snapshot serialization.
* Sort failures and indices.
* Add filter for filtering snapshots by their repository.
* Surface states with humanized text, icons, and tooltips where necessary.
* Fix pluralization of seconds.
* Surface failures tab even if there are none.
- Display a '-' for missing times and durations.
- Create DataPlaceholder component.
* [SR] Polish repositories UX (#35123)
* Refactor repository detail panel to load repository based directly on route param.
* Display repository detail panel while table is loading.
* Make 'Edit repository' table action a link instead of a button.
* Render disabled EuiSelect as a readonly EuiFieldText.
* Prepend HDFS URI with hdfs:// protocol.
* Present scheme options for Read-Only URL repository as a select.
* [SR] Add client-side validation to repository form and link to snapshots from details (#35238)
* Add client side repository form validation, extract `flatten` into common lib
* Add snapshot count to repository details and link to snapshot list
* Reset validation when changing repository type
* Fix snapshot list filter deep linking for repository names with slashes and spaces
* Fix imports
* PR feedback
* [SR] Design and copywriting fixes (#35591)
* Split repository form into two steps; move `clean_settings.ts` to server
* Default to snapshots tab, adjust snapshot empty prompt, add app description
* Add minimum timeout to list view requests to avoid flicker, use EuiEmptyPrompt for loading screen, add doc link to settings step
* Add information about snapshots to delete repository behavior, add doc link for source only toggle, add size notation help text
* Add main doc link
* Copywriting and i18n fixes, and add some common settings to third party repo types
* Add fields to third party repo detail panel
* More copywriting fixes
* Use spinner for duration and end time if snapshotting is still in progress
* Show all repository type options, mark missing plugins
* Revert "Show all repository type options, mark missing plugins"
This reverts commit
|
||
---|---|---|
.. | ||
.github | ||
build_chromium | ||
common | ||
dev-tools | ||
plugins | ||
scripts | ||
server/lib | ||
tasks | ||
test | ||
test_utils | ||
typings | ||
.gitignore | ||
.kibana-plugin-helpers.json | ||
gulpfile.js | ||
index.js | ||
package.json | ||
README.md | ||
tsconfig.json |
Elastic License Functionality
This directory tree contains files subject to the Elastic License. The files subject to the Elastic License are grouped in this directory to clearly separate them from files licensed under the Apache License 2.0.
Development
By default, Kibana will run with X-Pack installed as mentioned in the contributing guide.
Elasticsearch will run with a basic license. To run with a trial license, including security, you can specifying that with the yarn es
command.
Example: yarn es snapshot --license trial --password changeme
By default, this will also set the password for native realm accounts to the password provided (changeme
by default). This includes that of the kibana
user which elasticsearch.username
defaults to in development. If you wish to specific a password for a given native realm account, you can do that like so: --password.kibana=notsecure
Testing
Running specific tests
Test runner | Test location | Runner command (working directory is kibana/x-pack) |
---|---|---|
Jest | x-pack/**/*.test.js x-pack/**/*.test.ts |
cd x-pack && node scripts/jest -t regexp [test path] |
Functional | x-pack/test/*integration/**/config.js x-pack/test/*functional/config.js |
node scripts/functional_tests_server --config x-pack/test/[directory]/config.js node scripts/functional_test_runner --config x-pack/test/[directory]/config.js --grep=regexp |
Examples:
- Run the jest test case whose description matches 'filtering should skip values of null':
cd x-pack && yarn test:jest -t 'filtering should skip values of null' plugins/ml/public/explorer/explorer_charts/explorer_charts_container_service.test.js
- Run the x-pack api integration test case whose description matches the given string:
node scripts/functional_tests_server --config x-pack/test/api_integration/config.js
node scripts/functional_test_runner --config x-pack/test/api_integration/config.js --grep='apis Monitoring Beats list with restarted beat instance should load multiple clusters'
In addition to to providing a regular expression argument, specific tests can also be run by appeding .only
to an it
or describe
function block. E.g. describe(
to describe.only(
.
Running all tests
You can run unit tests by running:
yarn test
If you want to run tests only for a specific plugin (to save some time), you can run:
yarn test --plugins <plugin>[,<plugin>]* # where <plugin> is "reporting", etc.
Debugging browser tests
yarn test:browser:dev
Initializes an environment for debugging the browser tests. Includes an dedicated instance of the kibana server for building the test bundle, and a karma server. When running this task the build is optimized for the first time and then a karma-owned instance of the browser is opened. Click the "debug" button to open a new tab that executes the unit tests.
Run single tests by appending grep
parameter to the end of the URL. For example http://localhost:9876/debug.html?grep=ML%20-%20Explorer%20Controller
will only run tests with 'ML - Explorer Controller' in the describe block.
Running server unit tests
You can run server-side unit tests by running:
yarn test:server
Running functional tests
The functional UI tests, the API integration tests, and the SAML API integration tests are all run against a live browser, Kibana, and Elasticsearch install. Each set of tests is specified with a unique config that describes how to start the Elasticsearch server, the Kibana server, and what tests to run against them. The sets of tests that exist today are functional UI tests (specified by this config), API integration tests (specified by this config), and SAML API integration tests (specified by this config).
The script runs all sets of tests sequentially like so:
- builds Elasticsearch and X-Pack
- runs Elasticsearch with X-Pack
- starts up the Kibana server with X-Pack
- runs the functional UI tests against those servers
- tears down the servers
- repeats the same process for the API and SAML API integration test configs.
To do all of this in a single command run:
node scripts/functional_tests
Running UI tests
To run only the functional UI tests:
node scripts/functional_tests --config test/functional/config
It does the same as the previous command, except that it only does setup/test/teardown for the UI tests.
Running API integration tests
API integration tests are run with a unique setup usually without UI assets built for the Kibana server.
API integration tests are intended to test only programmatic API exposed by Kibana. There is no need to run browser and simulate user actions, which significantly reduces execution time. In addition, the configuration for API integration tests typically sets optimize.enabled=false
for Kibana because UI assets are usually not needed for these tests.
To run only the API integration tests:
node scripts/functional_tests --config test/api_integration/config
Running SAML API integration tests
We also have SAML API integration tests which set up Elasticsearch and Kibana with SAML support. Run only API integration tests with SAML enabled like so:
node scripts/functional_tests --config test/saml_api_integration/config
Running and building Jest integration tests
Jest integration tests can be used to test behavior with Elasticsearch and the Kibana server.
node scripts/jest_integration
An example test exists at test_utils/jest/integration_tests/example_integration.test.ts
Running Reporting functional tests
See here for more information on running reporting tests.
Developing functional tests
If you are developing functional tests then you probably don't want to rebuild Elasticsearch and wait for all that setup on every test run, so instead use this command to build and start just the Elasticsearch and Kibana servers:
node scripts/functional_tests_server
After the servers are started, open a new terminal and run this command to run just the tests (without tearing down Elasticsearch or Kibana):
# Make sure you are in the x-pack directory
cd x-pack
# Invoke the functional_test_runner from Kibana. Try sending --help to learn more
node ../scripts/functional_test_runner
For both of the above commands, it's crucial that you pass in --config
to specify the same config file to both commands. This makes sure that the right tests will run against the right servers. Typically a set of tests and server configuration go together.
Read more about how the scripts work here.
For a deeper dive, read more about the way functional tests and servers work here.