diff --git a/.node-version b/.node-version index 80895903a15c8..cc2fbe89b6c7c 100644 --- a/.node-version +++ b/.node-version @@ -1 +1 @@ -4.3.0 +4.3.2 diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 7e958eed0498e..6cbdae5c3e236 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -13,7 +13,7 @@ At any given time the Kibana team at Elastic is working on dozens of features an Let's just get this out there: **Feel free to +1 an issue**. That said, a +1 isn't a vote. We keep up on highly commented issues, but comments are but one of many reasons we might, or might not, work on an issue. A solid write up of your use case is more likely to make your case than a comment that says *+10000*. #### My issue isn't getting enough attention -First of all, sorry about that, we want you to have a great time with Kibana! You should join us on IRC (#kibana on freenode) and chat about it. Github is terrible for conversations. With that out of the way, there are a number of variables that go into deciding what to work on. These include priority, impact, difficulty, applicability to use cases, and last, and importantly: What we feel like working on. +First of all, sorry about that, we want you to have a great time with Kibana! You should join us on IRC ([#kibana](https://kiwiirc.com/client/irc.freenode.net/?#kibana) on freenode) and chat about it. Github is terrible for conversations. With that out of the way, there are a number of variables that go into deciding what to work on. These include priority, impact, difficulty, applicability to use cases, and last, and importantly: What we feel like working on. ### I want to help! **Now we're talking**. If you have a bugfix or new feature that you would like to contribute to Kibana, please **find or open an issue about it before you start working on it.** Talk about what you would like to do. It may be that somebody is already working on it, or that there are particular issues that you should know about before implementing the change. @@ -111,94 +111,90 @@ Before running the tests you will need to install the projects dependencies as d Once that is complete just run: -```sh +``` +sh npm run test && npm run build ``` -#### Testing and debugging tests +#### Debugging unit tests The standard `npm run test` task runs several sub tasks and can take several minutes to complete, making debugging failures pretty painful. In order to ease the pain specialized tasks provide alternate methods for running the tests. -
-
npm run test:quick
-
Runs both server and browser tests, but skips linting
- -
npm run test:server or npm run test:browser
-
Runs the tests for just the server or browser
-
npm run test: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. -
- -
+`npm run test:quick` +Runs both server and browser tests, but skips linting -
npm run mocha [test file or dir] or npm run mocha:debug [test file or dir]
-
- Run a one off test with the local project version of mocha, babel compilation, and optional debugging. Great - for development and fixing individual tests. -
-
+`npm run test:server` +Run only the server tests -Distributable packages can be found in `target/` after the build completes. - -#### Building OS packages - -Packages are built using fpm, pleaserun, dpkg, and rpm. fpm and pleaserun can be installed using gem. Package building has only been tested on Linux and is not supported on any other platform. -```sh -gem install pleaserun -apt-get install ruby-dev -gem install fpm -npm run build:ospackages -``` +`npm run test:browser` +Run only the browser tests -To specify a package to build you can add `rpm` or `deb` as an argument. -```sh -npm run build:ospackages -- --rpm -``` +`npm run test: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. +![Browser test debugging](http://i.imgur.com/DwHxgfq.png) -### Functional UI Testing +`npm run mocha [test file or dir]` or `npm run mocha:debug [test file or dir]` +Run a one off test with the local project version of mocha, babel compilation, and optional debugging. Great +for development and fixing individual tests. -#### Handy references +#### Unit testing plugins +This should work super if you're using the [Kibana plugin generator](https://github.com/elastic/generator-kibana-plugin). If you're not using the generator, well, you're on your own. We suggest you look at how the generator works. -- https://theintern.github.io/ -- https://theintern.github.io/leadfoot/Element.html +`npm run test:dev -- --kbnServer.testsBundle.pluginId=some_special_plugin --kbnServer.plugin-path=../some_special_plugin` +Run the tests for just your particular plugin. Assuming you plugin lives outside of the `installedPlugins directory`, which it should. -#### Running tests using npm task: +#### Running browser automation tests: *The Selenium server that is started currently only runs the tests in Firefox* -To run the functional UI tests use the following commands - -
- -
npm run test:ui
-
Run the functional UI tests one time and exit. This is used by the CI systems and is great for quickly checking that things pass. It is essentially a combination of the next two tasks.
+The following will start Kibana, Elasticsearch and Selenium for you. To run the functional UI tests use the following commands -
npm run test:ui:server
-
Start the server required for the test:ui:runner tasks. Once the server is started test:ui:runner can be run multiple times without waiting for the server to start.
+`npm run test:ui` +Run the functional UI tests one time and exit. This is used by the CI systems and is great for quickly checking that things pass. It is essentially a combination of the next two tasks. -
npm run test:ui:runner
-
Execute the front-end selenium tests. This requires the server started by the test:ui:server task.
+`npm run test:ui:server` +Start the server required for the `test:ui:runner` tasks. Once the server is started `test:ui:runner` can be run multiple times without waiting for the server to start. -
+`npm run test:ui:runner` +Execute the front-end selenium tests. This requires the server started by the `test:ui:server` task. -#### Running tests locally with your existing (and already running) ElasticSearch, Kibana, and Selenium Server: +##### If you already have ElasticSearch, Kibana, and Selenium Server running: -Set your es and kibana ports in `test/intern.js` to 9220 and 5620, respecitively. You can configure your Selenium server to run the tests on Chrome,IE, or other browsers here. +Set your es and kibana ports in `test/intern.js` to 9220 and 5620, respectively. You can configure your Selenium server to run the tests on Chrome,IE, or other browsers here. Once you've got the services running, execute the following: -```sh +``` +sh npm run test:ui:runner ``` -#### General notes: +#### Browser automation notes: - Using Page Objects pattern (https://theintern.github.io/intern/#writing-functional-test) -- At least the initial tests for the Settings, Discover, and Visualize tabs all depend on a very specific set of logstash-type data (generated with makelogs). Since that is a static set of data, all the Discover and Visualize tests use a specific Absolute time range. This gaurantees the same results each run. +- At least the initial tests for the Settings, Discover, and Visualize tabs all depend on a very specific set of logstash-type data (generated with makelogs). Since that is a static set of data, all the Discover and Visualize tests use a specific Absolute time range. This guarantees the same results each run. - These tests have been developed and tested with Chrome and Firefox browser. In theory, they should work on all browsers (that's the benefit of Intern using Leadfoot). - These tests should also work with an external testing service like https://saucelabs.com/ or https://www.browserstack.com/ but that has not been tested. +- https://theintern.github.io/ +- https://theintern.github.io/leadfoot/Element.html + +#### Building OS packages + +Packages are built using fpm, pleaserun, dpkg, and rpm. fpm and pleaserun can be installed using gem. Package building has only been tested on Linux and is not supported on any other platform. +```sh +gem install pleaserun +apt-get install ruby-dev +gem install fpm +npm run build:ospackages +``` + +To specify a package to build you can add `rpm` or `deb` as an argument. +```sh +npm run build:ospackages -- --rpm +``` + +Distributable packages can be found in `target/` after the build completes. ## Submitting a pull request @@ -225,6 +221,7 @@ Remember, someone is blocked by a pull awaiting review, make it count. Be thorou 1. **Understand the issue** that is being fixed, or the feature being added. Check the description on the pull, and check out the related issue. If you don't understand something, ask the person the submitter for clarification. 1. **Reproduce the bug** (or the lack of feature I guess?) in the destination branch, usually `master`. The referenced issue will help you here. If you're unable to reproduce the issue, contact the issue submitter for clarification 1. **Check out the pull** and test it. Is the issue fixed? Does it have nasty side effects? Try to create suspect inputs. If it operates on the value of a field try things like: strings (including an empty string), null, numbers, dates. Try to think of edge cases that might break the code. +1. **Merge the target branch**. It is possible that tests or the linter have been updated in the target branch since the pull was submitted. Merging the pull could cause core to start failing. 1. **Read the code**. Understanding the changes will help you find additional things to test. Contact the submitter if you don't understand something. 1. **Go line-by-line**. Are there [style guide](https://github.com/elastic/kibana/blob/master/STYLEGUIDE.md) violations? Strangely named variables? Magic numbers? Do the abstractions make sense to you? Are things arranged in a testable way? 1. **Speaking of tests** Are they there? If a new function was added does it have tests? Do the tests, well, TEST anything? Do they just run the function or do they properly check the output? diff --git a/STYLEGUIDE.md b/STYLEGUIDE.md index 676b007a6629e..f13265ea3d15a 100644 --- a/STYLEGUIDE.md +++ b/STYLEGUIDE.md @@ -586,7 +586,7 @@ Use slashes for both single line and multi line comments. Try to write comments that explain higher level mechanisms or clarify difficult segments of your code. **Don't use comments to restate trivial things**. -***Exception:*** Comment blocks describing a function and it's arguments (docblock) should start with `/**`, contain a single `*` at the begining of each line, and end with `*/`. +***Exception:*** Comment blocks describing a function and its arguments (docblock) should start with `/**`, contain a single `*` at the beginning of each line, and end with `*/`. *Right:* @@ -656,7 +656,7 @@ function ClassName() { var ClassName = function () {}; ``` -### Inhertiance should be done with a utility +### Inheritance should be done with a utility While you can do it with pure JS, a utility will remove a lot of boilerplate, and be more readable and functional. @@ -685,7 +685,7 @@ Square.prototype = Object.create(Shape); ### Keep Constructors Small -It is often the case that there are properties that can't be defined on the prototype, or work that needs to be done to completely create an object (like call it's Super class). This is all that should be done within constructors. +It is often the case that there are properties that can't be defined on the prototype, or work that needs to be done to completely create an object (like call its Super class). This is all that should be done within constructors. Try to follow the [Write small functions](#write-small-functions) rule here too. @@ -775,7 +775,7 @@ Several already exist, and can be found in `src/kibana/utils/_mixins.js` ## Filenames -All filenames should use `snake_case` and *can* start with an underscore if the module is not intended to be used outside of it's containing module. +All filenames should use `snake_case` and *can* start with an underscore if the module is not intended to be used outside of its containing module. *Right:* - `src/kibana/index_patterns/index_pattern.js` @@ -858,7 +858,7 @@ app.service('CustomService', function(Promise, otherDeps) { ### Routes -Angular routes are defined using a custom require modules named `routes` that remove much of the required boilerplate. +Angular routes are defined using a custom require module named `routes` that remove much of the required boilerplate. ```js require('ui/routes') @@ -871,7 +871,7 @@ require('ui/routes') ## Multiple attribute values -When a node has multiple attributes that would cause it to exceed the line character limit, each attribute including the first should be on its own line with a single indent. Also, when a node that is styled in this way has child nodes, there should be a blank line between the openening parent tag and the first child tag. +When a node has multiple attributes that would cause it to exceed the line character limit, each attribute including the first should be on its own line with a single indent. Also, when a node that is styled in this way has child nodes, there should be a blank line between the opening parent tag and the first child tag. ``` - \ No newline at end of file + diff --git a/src/ui/public/visualize/visualize_legend.js b/src/ui/public/visualize/visualize_legend.js index 9d3edea59b79d..bd2cbe281ec3c 100644 --- a/src/ui/public/visualize/visualize_legend.js +++ b/src/ui/public/visualize/visualize_legend.js @@ -29,12 +29,18 @@ uiModules.get('kibana') refresh(); }); - $scope.highlightSeries = function (label) { - $('[data-label]', $elem.siblings()).not('[data-label="' + label + '"]').css('opacity', 0.5); + $scope.highlight = function (event) { + var el = event.currentTarget; + var handler = $scope.renderbot.vislibVis.handler; + if (!handler) return; + handler.highlight.call(el, handler.el); }; - $scope.unhighlightSeries = function () { - $('[data-label]', $elem.siblings()).css('opacity', 1); + $scope.unhighlight = function (event) { + var el = event.currentTarget; + var handler = $scope.renderbot.vislibVis.handler; + if (!handler) return; + handler.unHighlight.call(el, handler.el); }; $scope.setColor = function (label, color) { diff --git a/src/ui/ui_app_collection.js b/src/ui/ui_app_collection.js index a00d9646d557f..b39c8c57ea2f3 100644 --- a/src/ui/ui_app_collection.js +++ b/src/ui/ui_app_collection.js @@ -1,6 +1,6 @@ import _ from 'lodash'; import UiApp from './ui_app'; -let Collection = require('requirefrom')('src')('utils/Collection'); +import Collection from '../utils/Collection'; let byIdCache = Symbol('byId'); diff --git a/tasks/config/babel.js b/tasks/config/babel.js index 3e16bf5959be9..3ea329e6dbcd9 100644 --- a/tasks/config/babel.js +++ b/tasks/config/babel.js @@ -1,5 +1,5 @@ let { defaults } = require('lodash'); -let babelOptions = require('requirefrom')('src')('optimize/babelOptions'); +let babelOptions = require('../../src/optimize/babelOptions'); module.exports = { build: { diff --git a/tasks/config/esvm.js b/tasks/config/esvm.js index 495c391ba7a03..89bf4115333b7 100644 --- a/tasks/config/esvm.js +++ b/tasks/config/esvm.js @@ -2,7 +2,7 @@ module.exports = function (grunt) { var resolve = require('path').resolve; var directory = resolve(__dirname, '../../esvm'); var dataDir = resolve(directory, 'data_dir'); - var uiConfig = require('requirefrom')('test')('serverConfig'); + var uiConfig = require('../../test/serverConfig'); return { options: { diff --git a/test/fixtures/scenarios/logstashFunctional/makelogsIndexDefinition.js b/test/fixtures/scenarios/logstashFunctional/makelogsIndexDefinition.js index 67ecf94ca3013..95b416ea852f0 100644 --- a/test/fixtures/scenarios/logstashFunctional/makelogsIndexDefinition.js +++ b/test/fixtures/scenarios/logstashFunctional/makelogsIndexDefinition.js @@ -21,7 +21,6 @@ module.exports = { 'mapping': { 'type': 'string', 'index': 'analyzed', - 'omit_norms': true, 'fields': { 'raw': { 'index': 'not_analyzed', diff --git a/test/fixtures/scenarios/makelogs/makelogsIndexDefinition.js b/test/fixtures/scenarios/makelogs/makelogsIndexDefinition.js index 67ecf94ca3013..95b416ea852f0 100644 --- a/test/fixtures/scenarios/makelogs/makelogsIndexDefinition.js +++ b/test/fixtures/scenarios/makelogs/makelogsIndexDefinition.js @@ -21,7 +21,6 @@ module.exports = { 'mapping': { 'type': 'string', 'index': 'analyzed', - 'omit_norms': true, 'fields': { 'raw': { 'index': 'not_analyzed', diff --git a/test/utils/kbn_server.js b/test/utils/kbn_server.js index 35a0bc3aa1c59..eb77401615dc3 100644 --- a/test/utils/kbn_server.js +++ b/test/utils/kbn_server.js @@ -1,11 +1,8 @@ import { defaultsDeep, set } from 'lodash'; -import requirefrom from 'requirefrom'; import { header as basicAuthHeader } from './base_auth'; import { kibanaUser, kibanaServer } from '../shield'; - -const src = requirefrom('src'); -const KbnServer = src('server/KbnServer'); -const fromRoot = src('utils/fromRoot'); +import KbnServer from '../../src/server/KbnServer'; +import fromRoot from '../../src/utils/fromRoot'; const SERVER_DEFAULTS = { server: {