* Add option to functional test server to run elasticsearch from install dir
* Fix variable
* Fix server CLI test
* Updates to include install path in esFrom command line option
* Fix snapshot
* Update args/cli tests
* Keep default snapshot in args/help
This was previously defined in uiExports.app, which limited plugins which are not an app of providing a stylesheet. This allows any plugin to define a stylesheet which will be available on page load.
I was surprised when I tried to spread a `Set` in TypeScript and the browser complained about `Set.slice()` not being defined. This is because TypeScript does not automatically enable support for iterators when targeting earlier ES versions, like we do in the browser, unless you use the `"downlevelIteration": true` compiler option. This injects some helpers into the necessary files for reading/spreading iterators, which can be stuffed behind an import statement with using the `"importHelpers": true` compiler option and include `tslib` in our dependencies. This is already a dependency of several of our packages, so it shouldn't cause any additional modules.
The plugin helper tests have failed due to timeouts every once and a while, which makes sense because they run a bunch of CLI tasks, so this just moved them to the jest integration tests where tests can take a little longer to run.
I'd really like to upgrade to Typescript 3 for its `unknown` type, but we need to upgrade to `jest@23` to support a recent version of `ts-jest@23`.
The [jest changelog](https://github.com/facebook/jest/blob/master/CHANGELOG.md) breaks down the breaking changes in 23.x, but I found it to be slightly incomplete so I've broken down the changes that actually caused breaks for us here, and addressed each in individual commits to make review a little easier:
- the `testURL` config default was changed from `about:blank` to `http://localhost`
- this cause some XHR requests powered by JSdom to start failing. It seems these requests just do nothing in master but start to fail when JSdom is initialized with an actual URL... I think we would ideally stop sending meaningless XHR requests in the tests, but it was a lot easier to just set the config to `about:blank` for now, and we can worry about cleanup later if necessary
- `expect(...).toThrow()` only passes if an actual error was thrown.
- In two places in the index pattern code we were throwing strings, which broke the assertions. Fortunately/Unfortunately the errors are not being consumed by anything, so I was able to wrap them in `new Error()` without causing any issues.
- snapshots of mock functions now include a `results` array, detailing the return values of the function
- React fragments are now serialized as `<React.Fragment>` instead of `<UNDEFINED>`
- undefined props in React components are now stripped from snapshots
- minor changes to the ordering of mocks, imports resolution, and before hooks caused the uiSettings API tests to start breaking, but I'm replacing them with totally new tests in #22694 so I just deleted them here
- mocks created with `jest.spyOn()` that are restored now have their `mock.calls` reset, so some of the kbn-pm tests stated failing. This was fixed by restoring them with `jest.restoreAllMocks()` rather than trying to do it before the assertions
* Add `default` and `baseInterval` configuration ability to date histogram EditorConfig
* Change EditorConfig `warning` to `help`, show `help` below date histogram and histogram interval inputs
This is an attempt to write a log capture integration for the functional test runner that will collect all log output written during a test, prevent it from being written to stdout to lower the amount of work Jenkins master has to do and include the entire log output for each test in the junit report. I'm slightly concerned about the amount of memory we'll be using to store a copy of the logs for each test, but streaming the XML report isn’t easy and there doesn’t seem to be a library out there to help. If we decide it’s torally necessary we might be able to figure it out.
* [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
* [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
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.
A couple times while debugging failures in `functional_tests(_servers)` with people I've asked for stack traces and received responses like "that's all there is", and it turns out that's right, because the cli's are passing the error object directly to `chalk.red()`, which converts it into a string that only includes the message. This pr moves the common operations from `run_tests/cli.js` and `run_servers/cli.js` into `lib/run_cli` and includes test for the common functionality there, as well as a common error printing logic that still includes the red message, but also includes a stack trace that will help out a lot in debugging.
* Add Guideline for i18n engine
* Update Guideline according to changes in i18n engine.
* Update examples in Guideline
* typo
* improve i18n guideline: add table for better view, use single quotes for js strings, fix description for testing, use uniq "message id" name
* fix readme description for guideline
Co-authored-by: maryia-lapata "mary.lopato@gmail.com"
* [kbn-test] convert kibana-install-dir flag to installDir option
* [kbn-test] replicate kibana-install-dir handling to startServers
* [ftr] try running functional tests in production in CI
* Revert "[ftr] try running functional tests in production in CI"
This reverts commit e5b94aa024.
* [core/public/legacyPlatform] exclude ui/test_harness from the distributable
* [optimizer] fix `process.env.IS_KIBANA_DISTRIBUTABLE` definition
* [optimizer] only define `process.env.IS_KIBANA_DISTRIBUTABLE` when needed
Adding a `webpack.DefinePlugin` slows down the optimizer a small amount,
so only apply it when it is necessary, and skip it if it is going to
be defined as "false".
* [kbn-test/startServer] don't run in --dev mode if running from dist
* [ftr/kibanaServer/version] attach `-SNAPSHOT` suffix to version if running build_snapshot
* set kibana locale in kibana.yml config
* remove accept-language-parser
* remove unnecessary tests
* fix readme description, fix description for locale in kibana.yml
* add point, that i18n.locale option should have exact match
* update kbn/i18n README
* Update README.md
* use getUiTranslations in render_mixin, remove i18n_mixin
* move registering translation files to mixin function
This upgrades prettier to version 1.14.0. The main motivation is to gain support for the new TypeScript language features introduced in 2.9 and 3.0.
Prettier versions 1.13 and 1.14 also introduced some other JavaScript and TypeScript style improvements resulting in a few small line break and parenthesis changes.
The relevant release notes are:
* [Prettier 1.13.0 Release Notes](https://prettier.io/blog/2018/05/27/1.13.0.html)
* [Prettier 1.40.0 Release Notes](https://prettier.io/blog/2018/07/29/1.14.0.html)
* Add unit-tests for i18n engine
* tests for angular wrappers under i18n engine
* split to packages in accordance to specific library
* split to packages depending on tech and environment
* make env modules names consistent
* remove intl polyfilling
* move laoder to root, i18n folder to core
* Add unit-tests for i18n engine
* tests for angular wrappers under i18n engine
* rebase on split package, injectIntl component
* eslint fixes
* use method names for checking, test i18n-values in directive
* use real html content while testing directive
* add test for angular directive without values
Fixes#20694
Implements super basic new platform `core` system, which includes two services: `core.injectedMetadata` and `core.legacyPlatform`. The `core` currently has two responsibilities:
1. read the metadata from the DOM and initialize the `ui/metadata` module with legacy metadata, proving out how we plan to expose data from the new platform through the existing APIs/modules to the legacy platform.
2. bootstrap the legacy platform by loading either `ui/chrome` or `ui/test_harness`
Because `core` mutates the `ui/metadata` module before bootstrapping the legacy platform all existing consumers of `ui/metadata` won't be impacted by the fact that metadata loading was moved into the new platform. We plan to do this for many other services that will need to exist in both the legacy and new platforms, like `ui/chrome` (see #20696).
* bump eui
* Fixed breaking `EuiPage` changes
Mainly adding `EuiPageBody`’s where there were none
* bump to 3.0, remove duplicate declaration of EuiFlyoutBody, update jest snapshots
* bump eui
* bump to 3.0, remove duplicate declaration of EuiFlyoutBody, update jest snapshots
* Update jest snapshots in xpack
<!--
Thank you for your interest in and contributing to Kibana! There
are a few simple things to check before submitting your pull request
that can help with the review process. You should delete these items
from your submission, but they are here to help bring them to your
attention.
- Have you signed the [contributor license agreement](https://www.elastic.co/contributor-agreement)?
- Have you followed the [contributor guidelines](https://github.com/elastic/kibana/blob/master/CONTRIBUTING.md)?
- If submitting code, have you included unit tests that cover the changes?
- If submitting code, have you tested and built your code locally prior to submission with `yarn test && yarn build`?
- If submitting code, is your pull request against master? Unless there is a good reason otherwise, we prefer pull requests against master and will backport as needed.
-->
Make relevant generated files use snakeCase instead of kebabCase
Closes#20524
This upgrades TypeScript to version 2.9.2. My main motivation is the support for generic type arguments in JSX elements and tagged templates (e.g. for `styled-components`).
Problems arising from breaking changes in the new TypeScript version have been mitigated by:
* setting the `keyofStringsOnly` option until impacted code has been
future-proofed
* Restricting some joi-related generics
See the [release notes](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-2-9.html) for details.
Some follow-up tasks should be:
* Update EUI to support the new `keyof` behaviour
* Update new platform TypeScript code to support new `keyof` behaviour
* Remove `keyofStringsOnly` setting
* split to packages in accordance to specific library
* split to packages depending on tech and environment
* make env modules names consistent
* remove intl polyfilling
* move laoder to root, i18n folder to core
* Add missing peer dependency and upgraded to new import resolver kibana
* Fixed template code to follow eslint rules
* Fix lint script to lint all files in the generated dir
* More precise slurp :p
