Compressor redux

[cantsin]

Link to ZenHub issue.

What does this change?

Second try at implementing django-compressor functionality. Believe it or not, the hero.png image (which we never use) is indeed needed and breaks manifest storage outright if we omit this image. Why? Well, the USWDS CSS specifies background-image:url("../img/hero.png"); which the Django manifest storage backend picks up and then subsequently crashes during collectstatic when this file is not found. tl;dr: I believe this missing, unused file is what broke deployment last time (really).

The rest is identical to before, except for a couple of small things. We can use the built in S3ManifestStaticStorage instead of monkey patching classes. Two CSS url references have been tweaked so that they are properly fetched from S3.

But most exciting is the localstack documentation I've thrown in, which explains how to set up an identical-ish production environment locally.

Screenshots (for front-end PR):

Checklist:

Author

• If this is a story, run locally and check to make sure all Acceptance Criteria are met. (If any criteria are unclear, ask about them.).
• Check for, document, and establish a testing plan for any behavior that may vary across environments or is otherwise difficult to test.
• Check for accessibility.
• Tests pass.

Reviewer

• If this is a story, run locally and check to make sure all Acceptance Criteria are met. (If any criteria are unclear, ask about them.).
• Check for any behavior that may vary across environments or is difficult to test, and ensure that it is well-understood, documented, and that there is a testing plan in place.
• Re-check for accessibility.
• Tests pass.

Notes for reviewer:

See PR instructions doc for full pull request review instructions.

[cantsin]

@Jkrzy flagging you as a reviewer too -- oddly enough Github is not populating your username in the reviewers field for whatever reason.

[cantsin]

Anyway, I'd like one of y'all to go through the documentation and let me know what worked, what was unclear, what could be improved. Thanks!

[Jkrzy]

This is :amaze:ing @cantsin!!!

Running through the docs I get tripped up on collectstatic with:

s3_1 | 2021-01-07T15:23:09:INFO:localstack.services.edge: Unable to find forwarding rule for host "s3:4566"

and this exception from boto: botocore.exceptions.ClientError: An error occurred (404) when calling the PutObject operation: Not Found

Did you hit this in local testing?

[cantsin]

@Jkrzy I have not gotten that error! To double check the obvious, did you rebuild the docker-compose image? I just ran through the steps again myself and so far I don't see that error.

• Does http://localhost:4566/health?reload show the s3 service running?
• If you do docker-compose run web curl http://s3:4566/health what shows up?

These two test external and internal access to the localstack edge port, respectively.

[cantsin]

@Jkrzy updated to address the issue we found last Friday. Please note that you will need to remove your local S3 bucket and re-create it (since collectstatic will skip if the file is already on S3 and therefore not save to staticfiles in the container as per our new storage class). Alternatively, I think removing the files: aws s3 rm --recursive s3://crt-portal/ --endpoint-url=http://localhost:4566 will also work.

Tested this time by doing git clean -fxd beforehand 😀

[Jkrzy]

Thanks @cantsin! We're super close but this latest change reverts to the non-manifesting storage implementation.

[Jkrzy]

Looks good, thanks for sticking with this one @cantsin!