Build on Federalist; remove build dir from git

[shawnbot]

This PR solves #23 by removing the build directory from git and leveraging Federalist's new npm script support. This means no more convoluted Jekyll -> plugin -> shell script -> npm messiness! I've also provided a fix for #29 along the way.

You can see it on Federalist staging! It also generates a build.log to provide us with some clues if things go wrong in the future.

Two things need to happen on Federalist before we should see this working in production:

• [x] Resolve merge conflicts
• [x] Merge 18F/federalist#707 and deploy to production
• [x] Deploy 18F/federalist-docker-build#13 to production
• [ ] Increase the memory limits on the Federalist build containers from 500MB to 1GB
• [ ] Push some changes to test

[shawnbot]

I'm pushing another commit to test out the Federalist build.

[shawnbot]

Still no dice, and the Federalist log says, "This build completed successfully." 😢

[shawnbot]

🚨 IT WORKS!! 🚨

[msecret]

The build process makes sense, I say :+1:

[shawnbot]

I'm refactoring to bring back the build directory and simplify the Jekyll setup; fingers crossed this builds too.

[shawnbot]

If this build is successful, fractal.js should no longer exist because it's never copied to the build directory.

[shawnbot]

Okay, so that previous build failed. I'm fixing up the Jekyll config to exclude the src directory and outputting the build log in build/log.txt so we can view it directly in the browser more easily.

[juliaelman]

@shawnbot nice work! ^5

At first glance, I think it is b/c this command is expecting the build dir to already be available we are having some breakage on Federalist.

[shawnbot]

Hmm, I thought that I did that in 39f6763440a2d374d75f0e7a3571649f6a8cc1e9, but it looks like the build/.gitkeep file didn't take.

[shawnbot]

Okay, I'm going to roll this back to dbeadf9752d94f5e22de183df08b154ce0f0f680 so we can close it this and move on.

[shawnbot]

We are back in business. @juliaelman, let's :shipit:

[juliaelman]

Making a note here from our conversation in Slack. The error is now solved, but the preview on the component page is now not showing, screenshot below:

Let's leave this PR until we have a conversation with @NoahKunin and @wslack tomorrow. It seems that we're stretching the limits of Federalist and it might be time to switch to cloud.gov 👍

[shawnbot]

Update! We're good to use Federalist, and we're going to work with the team to add more explicit support for npm-driven builds. In the meantime, we should figure out what we need to do to fix the broken previews in this branch.

[shawnbot]

Okay, so I opened up the Federalist previews so they're publicly visible, but now there's a new problem: I think that Federalist is setting the X-Frame-Options: DENY header on the S3 bucket, which Chrome dutifully obeys and prevents component previews in <iframe> elements from loading on pages like this one:

Strangely, this doesn't happen on the master preview. cc @jmhooper

[shawnbot]

Update: @jmhooper tells me that the X-Frame-Options header is set for all federalist.18f.gov responses. This effectively renders the <iframe> elements that Fractal relies upon to sandbox component previews unusable in Federalist branch previews. I've escalated this to a request for having preview URLs excluded from the header, but until then we're hosed. 😢

[wslack]

cc @NoahKunin to check this out per our brief office convo

More explanation from @shawnbot here: https://github.com/18F/federalist/issues/706

[NoahKunin]

Un-subbing since I approved this elsewhere. Nice work!

[shawnbot]

Okay, good times! Here's where we are right now:

• The site builds on the Federalist staging, as you can see here. (We can preview any branch publicly on staging now because I added the site there.)
• We need two things from Federalist in order to close this:
  1. Deploy 18F/federalist#707 to production
  2. Increase the memory limits on the Federalist build containers from 500MB to 1GB, which @jmhooper did to get Marigold working on the staging environment
• I honestly don't know how Federalist is publishing the build directory on production, which is what makes this URL instead of this one, but you need to append the build/ path to see the site on staging. I've filed ~18F/federalist#708~ 18F/federalist#180 to report this, because Federalist should obey the source: build line in the Jekyll configuration. I'm going to file another issue in this repo to track that.

[wslack]

@shawnbot one note, that https://github.com/18F/federalist/issues/180 has been opened in place of https://github.com/18F/federalist/issues/708

[wslack]

@shawnbot any negative impacts of increasing the memory limit? Can that be another issue for discussion on the Federalist repo?

[shawnbot]

Thanks, @wslack. Everyone: I've updated the PR description with the latest state of things and added a checklist for the remaining tasks, as well as a note that I've fixed #29 too.

[shawnbot]

@wslack I'm not sure about the memory limits; I think it just means that our container resources are more "expensive" in whatever way we pay for them. cc @jmhooper

[juliaelman]

@shawnbot just wanted to touch base on this issue, as there a lot of moving parts around the Githubs. It looks like there are three steps left in order for this pull request to be merged in?

[shawnbot]

@juliaelman It's true: this is super complicated. Two things to be updated on Federalist in production in order for this to move forward: the new build containers with npm support, and upped memory limits for them. I don't have a sense yet of if/when this will happen, but @wslack and @jmhooper are aware that these are blockers for this project.

[shawnbot]

I think the necessary changes for this (npm and 1G memory on build containers) are available on the "new" (GovCloud) Federalist. @wslack or @jmhooper, can you confirm?

[shawnbot]

OBE 💥