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
This is a manual revert of 28aa6c9, which is not very useful with the
new build tasks, completely brittle, and a flawed idea from the start. I
regret having written it.
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.
- Now you'll see a path of the parent dependencies when a dependency fails to licenses task, so you can identify the offending root dependency.
- ES2015ify the licenses task.
Production builds should never be published directly from a local
machine. Instead, the release command will now publish to a
commit-specific staging URL, so you use it to publish a release
candidate, and then when those builds have been verified, you need to
copy the RC builds from on the staging location on s3 to the production
folder.
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.
