Turns out our deploy step had a nasty bug where branches would collide if
they started with the name of another branch, for example `3d-tiles` would
try and delete the deployment files for `3d-tiles-transform`. This is
because AWS prefixes need to end with a trailing `/` in order to list
only child files. So `3d-tiles` would return all files from all branches
that start with `3d-tiles`, whereas `3d-tiles/` only gets files from
`3d-tiles` as desired.
For a pull request, the `TRAVIS_BRANCH` variable is always `master` this
causes deployment to deploy to the master branch instead of the branch
name (which is unavailable for pull requests). Even if the branch name
were available, forks that open pull requests could have name conflicts
with branches in the primary repository, so we wouldn't be able to deploy
them anyway.
Fixes#3937
This change allows travis to deploy the generate zip files and
npm packages in addition to the build output. Each package
gets a unique name based on branch name and build number.
Also updated deployment step not to delete these packages so that
they can be depended on until the branch is merged.
1. Running travis under node 4.3.x gives a decent improvement over 0.12.
2. Move `cloc` to the end of the build since it's the least important.
3. Take advantage of multiple cores for combine/minification
Number 3 reduced `makeZipFile` times on my machine from 5:40 to 2:30,
performance increases has transferred to travis as well. Because
travis reports 32 cores and trying to use them all results in
travis killing the build, I put in a hardcoded limit of 8 for now.
My approach is a little hacky (I exec a seprate gulp task passing a base64
encoded string on the command line), but I couldn't determine a better
way to handle it with gulp because there's no programmatic way to spawn
a task (I think this is being fixed in gulp 4, so we'll revisit when that
comes out).
buildApps technically depends on minifyRelease, but having it as a
dependancy means you can't run it on it's own without rebuilding the whole
thing (since we don't have incremental builds). combine should not have
ever been there to begin with.
1. Run non-webgl tests as part of travis using Electron. They run in both
module and release form.
2. Run cloc as part of the build process
3. jsHint no longer fails the gulp task when you run `npm run jsHint`,
since that behavior was really annoying. It still fails under travis or
when passed the `--failTaskOnError` option.
4. Improve log output by using travis folding commands. Each part of the
build is now collapsed into its own section.
5. Added `--suppressPassed` option to avoid showing passed tests in output.
Our travis log got too big and travis refused to show it (even with the
folding) unless you looked at raw test.
Apparently #3430 is still an issue and the travis_wait command added as
part of #3432 does not work as advertised. To address the issue once and
for all, I turned up the loglevel on requirejs so that it always outputs
progress to the build log (this was actually requested by @shunter and
a few others after the logging went away when we moved to gulp anyway).
Long story short we should finally stop seeing travis timeouts.
I also make jsHint run as a separate step and instead of `release` we
run `makeZipFile` to be sure the entire build process works. If
`makeZipFile` were to error, the previous configuration wouldn't have
caught it.
"gulp combine" output used to be copied to Build/Cesium, effectively overwritting any
minified version previously outputted there. With this commit, no more
copy is done by gulp.
We were writing out jsHintOptions with the `extends` attribute, which
wasn't working when loaded into the browser. Now the build process
loads the primary jshint file and modifies is to match the gallery
in order to write out a complete jsHintOptions object.
This could probably be a little more robust (since not all changes
to Apps/Sandcastle/.jshintrc get reflected automatically jsHintOptions,
but I doubt that will be an issue given that these files will rarely change.
Because jshint-eclipse does not support multiple `.jshintrc` files, I've
updated the root .jshintrc to include jasmine. This is then set to
false in lower-down `.jshintrc files using the extends capability.
This has the added benefit of meaning we no longer write out .jshintrc
files as part of the build step.
The only downside here is that jsHint in Eclipse thinks Jasmine globals
are okay in all of our Source files. However, that's not a big deal
and travis and our own jshint build step will detect the problem if
someone tries to call jasmine outside of the Specs directory.
So it turns out that jsHint no longer works on Node 0.10.x, which is
ancient anyway. So I updated Travis to use 0.12.x. I then decided to
update our .jshintrc to take advantage of the latest JSHint features and
that produced a TON of new (perfectly valid) errors about unused variables,
empty code blocks, and unused defined globals, which I have now cleaned up.
This also uncovered a bunch of other stuff that I also fixed.
In summary:
1. Update travis to use Node 0.12.x
2. Update .jshintrc to take advantage of new features
3. Fix bad code pointed out by said features
4. Remove all uneeded `jasmine` globals in spec files
5. Generate a `Specs` specific .jshintrc as part of the build which enables jasmine mode in jshint
6. Move `QuadtreePrimitive` to Development Sandcastle gallery.
7. Update NPM modules to latest versions.
8. Lock NPM modules to specific versions to avoid untested updates in the future.
9. Ran `sortRequires`
gulp-jshint does not return 1 on jsHint failure by default, instead it
prints the jsHint errors to the screen and cleanly exists with 0. This
adds their built-in "fail" reporter to return 1 and therefore allow
travis to fail as well.
1. Move all build related code to gulpfile.js
2. Add `npm` scripts for all gulp tasks so no one needs to install gulp globally.
3. Added new `jshint-watch` task for continually running jsHint on changed files and writing the results to the console.