* [devUtils/toolingLog] give tooling log configurable writers
* property shorthand
* remove redundant parameter
* call Error.captureStackTrace when subclassing Error
* describe why we skip stack trace logging for CliError
* always return true/false from log writers
* improve type definitions, writeTo is just an object with write method
* get rid of weird dedent for failures
* Retrofit the Bulk Uploader types combiner [ch2198]
fix usage collector, add comments to formatForBulk
remove unnecessary customizations
* override default format for bulk upload for usage type collectors
* rename to ignoreForInternalUploader
* collectors -> collectorSet
* use constant for kibana_stats type
* example of data formatting for bulk in function comment
* Consolidate map schemas to single defs. Add default setting to signal options modifications
* Revise checking for map vals to account for new joi defaults & cleanup. Separate logic for region and tile maps
* Formatting
* Combine refactored map schema with EMS schema updates
* Revise checking for map vals to account for new joi defaults & cleanup. Separate logic for region and tile maps
* Formatting
* Check for legacy values even if current values configured. Throw error if both configurations detected
* Fix regionmap assignment to use legacy when appropriate. Add more descriptive thrown error
* unskip filtering tests
* always navigate to landing page when trying to load a dashboard up
* more post test clean up - unpin the filter or it'll stick around for other tests.
Part of #20696, required for #20697
This migrates the `chrome.loadingCount` API to the new platform, which was not planned to happen before #20697 but is required as the UiSettingsClient uses the loading count to activate the global loading indicator in Kibana. This service is pretty simple, it allows adding an observable with `core.loadingCount.add(observable)` that will be subscribed to in order to contribute to the current "loading count", which can be retrieved with `core.loadingCount.get$()`.
The `ui/chrome/api/loading_count` module is taking the start contract from the service and re-exposing it via the existing `chrome.loadingCount` api that we have today, including `increment()`, `decrement()`, `subscribe()`, and the automatic watching of the loading count exposed by the angular `$http` service.
* [Tests] Add http integration test setup
* Base path tests
* SSL tests
* Eslint fixes
* Remove env from config schema
* Rename folders so no_rewrite and rewrite match configs/tests
* wip
* Use self-signed cert for SSL test
* Improve basepath tests
* Run base path proxy server in dev mode for now
* Remove env from x-pack reporting config
* Remove redundant base-path tests
* Test SSL with redirectHttpFromPort set
* Test SSL with redirectHttpFromPort set
* Flesh out comments
* Remove some cruft
* Add SSL tests to CI run
* Add opton to run chrome headless. Mainly for windows tests which can't use xvfb.
* Update from review comments
Make environment variable Boolean, remove single quotes from keys, remove window size.
Right now the functional tests are run against a distributable of Kibana in CI, but that distributable is running with `--env.name=development`. That causes the optimizer to run again before the tests can start and prevents the functional tests from running against the actual version of the application users will end up getting. This seems necessary for some tests, but not all of them, but I would like to get all of the tests running against the production version of Kibana soon.
This PR implements a second ftr config, `test/functional_production` that uses basically a copy of the `test/functional` config but with a few minor adjustments, removing the `--env.name=development` kbnServerArg and using a unique junit report name. To accomplish this I needed to modify the `@kbn/test` module to only pass the `--dev` flag to the Kibana server if it is being run in development mode, which it currently does by testing the args for `--env.name=development` or two args next to each other: `'--env.name'` and `'development'`. It does this by converting the `extraKbnOpts` option into an `addExtraKbnArgs` function, which is called with the final args just before passing them to the proc runner and given a chance to modify then after all other args are resolved (pulling from different places in config based on the build type, etc.)
Over the next couple weeks I'll push up PRs for individual test suites, migrating them over to the new production config, hopefully in a short period of time we will have all the function test suites back under that `test/function` config and can run them all against the Kibana server in production mode.
Add a welcome screen to Kibana home if this is a new Kibana instance.
New is determined by whether or not there are any index patterns
defined. Local storage is used to retain the user's decision to hide
the welcome screen.
* [DOCS] New tutorial for exploring Kibana with sample data set
* [DOCS] Incorporated review comments into sample tutorial
* [DOCS] GS: Edits for consistency
