The deepModules hacks in the build system were added to support the long
paths that resulted from npm2, but npm3 fundamentally addresses that
problem, so deepModules is no longer necessary. In practical terms, npm3
shouldn't ever cause path lengths to become so long that they trigger
path length problems on certain operating systems.
While working on some functional tests I had to re-run the `test:ui:server` task several times to rebuild the front-end assets. I'm not sure why that should be necessary, so this updates the server used in that specific task to auto-rebuild the assets.
The tests in master are currently failing regularly because our current browser tests are serious memory hogs. Investigation reveals that nearly every test is retaining all of the memory it causes to be allocated. We have made some progress to being able to diagnose the problems, but we expect that problem to take some serious work to fix. We need a short-term solution though, and this is it.
Rather than modify the bundling process, we will shard the top-level test suites by name. For now, we've created 4 shards, but adding new shards is trivial if we need to.
Sharding is accomplished by creating a murmur3 hash of the top level suite names, then bucketing based on the hash output. If a test suite resolves to shard2, but we are running shard1, we simply never pass the function to `mocha.describe()`. Rather than redefine every describe statement, we have shimmed the global `window.describe()` function to accomplish this.
Currently, `npm start` and `npm run test:dev` use the same webpack "working directory". This allows them to share assets, which seems great, but when webpack writes it's record-keeping files to disk it can lead to difficult to debug "Property call of undefined is not a function" errors. By writing it's optimization output to a different directory we prevent those collisions so that both the test server and the dev server can be run side-by-side
We do not release zip archives for any operating system except windows,
and we do not release tar.gz archives for windows. For consistency and
clarity sake, we'll explicitly list the architecture (x86) of the
windows build as well.
These changes are necessary for Kibana to be compatible with Elastic's
unified release process from 5.0 onward. The way artifacts get created
has not changed, but the naming conventions have.
- Add 'test:visualRegression' grunt task.
- Run 'test:visualRegression' as part of npm script 'test'.
- Add 'clean:screenshots task'.
- Clean screenshots/session when funtional tests are run.
The default behavior of the build task is to now apply the -snapshot
suffix dynamically rather than us manually hardcoding and managing it
within the source code itself. The `--release` flag will drop the
-snapshot suffix on a build, which should be used for any release
candidate.
The default behavior of the build task has also changed to create
rpm/deb packages as well. Since we've only confirmed that this works on
linux, you can override that behavior by passing `skip-os-packages`.
If you do not want to create any zip or tar.gz archives, you can pass
`--skip-archives`.
