According to https://blog.greenkeeper.io/announcing-native-lockfile-support-85381a37a0d0 it’s unnecessary since Sept 2018?!

Also remove the update step, it hasn’t been necessary since we began pinning the scratch-* packages.

We no longer use the “smoke” branch, nor do we push to master in order to deploy to S3. So remove these from the Travis config so it’s clearer what we actually use.

This flag essentially configures how much memory Node can use. If it’s too low, then Node processes may hang as Node spends time garbage collecting. Increasing it allows more memory to be used before garbage collection is necessary.  Travis VMs have 7.5GB of memory, so set the limit to just below that to avoid running out of memory completely.

These builds make our gh-pages branch too large for GitHub to handle.

They take up so much space and time, but aren't really looked at very much

Check if an NPM release just happened. And if so, tag the commit and push to GitHub.

Thanks to @paulkaplan for pairing on this

It doesn't affect greenkeeper subdirectories, which are the ones that cause the most issues. And now the prune step itself is breaking builds. So until it works better, remove this step.

This is different of what it is currently, where master/smoke goes to "latest" and develop goes to "develop"

Should only run if it’s running as cron

This interferes with our Fastly config, effectively disabling our gzip rule

Our deploys are complaining about how many times we set `user.name` and are failing.

The latest tag now is stable, and if you want the build from develop you can use `@develop` for that.

Continue to publish to latest for develop

This brings scratch-gui in line with the rest of the scratch-* packages, and what scratch-www needs for the project preview page.

build in production mode on travis

Unfortunately this will purge unnecessarily after gh-pages deployments, but that should not be an issue.

Currently using an unmerged PR in gh-pages. (Will update to an LLK fork if we decide to go this way.)

Move to Travis build stages to handle the multiple deploy methods by branch.

Stop "testing" in more Node versions than 6, as this is basically just testing our build tools (using a single Node version simplifies using build stages.)

Also add a `watch` command for testing static build output.