Build assets remotely.

[jmcarp]

Build assets on cloud foundry instead of building locally and uploading.
This simplifies deployment somewhat by offloading the work of asset
compilation from the developer's machine to Cloud Foundry and makes the
whole process just a little more reproducible.

• Symlink .gitignore to .cfignore
• Use both Python and Node buildpacks
• Build assets on push

[jmcarp]

Depends on https://github.com/18F/openFEC/pull/680.

[msecret]

When you say we're building on CF, what CF instance is it building on? I would think that we'd build assets on one CI server (like even Travis) and then upload or transfer to the final instance we're deploying to. If none of this makes any sense, let me know.

[jmcarp]

@msecret: The way this patch is written, each Cloud Foundry instance will build assets on deployment. Which, like you said, is it a little wasteful. Longer-term, it might be better to have the 0th instance build the assets and push to CloudFront, or something similar. But IMO it's still worth it to offload compilation to CF--it's one less thing that can break on our side. What do you think?

[arowla]

I was just pondering how to work out continuous deployment from Travis in light of our dual-app CF manifest (which is set up to push both repos at once, via a relative path) and the need to build stuff on the web app side (which is currently enabled by deploy.sh). This patch would indeed simplify things a lot! I am agnostic on whether it should be done on the CI or on CF. If I had to venture a guess, though, I'd think our flavor of CI is more likely to change than our CF environment anytime soon, so building on CF seems like a decent, if not the most efficient, plan.

[arowla]

This will need to have an npm install to get any new dependencies, too, no?

[jmcarp]

No. This patch uses both the python and node buildpacks, so CF autodetects package.json and runs npm install.

[arowla]

Ah, gotchya!