AWS Customer Support Win

Sarah Cassady | 28 Apr 2015 | Tags: aws, eb, git, rails

First, let me say that the AWS Elastic Beanstalk CLI plays very nicely with .gitignore out of the box, and is likely sufficient for typical application deployments. But there are some instances where distinct .gitignore and .ebignore exclude files are helpful, including:

• Precompiled assets: If you are precompiling production assets before deployment without using an asset host, these cannot be excluded in the .gitignore or else they will not be available in your app.
• Vendor packages: I’ve gotten into the habit of saving a copy of each third party package, library, or repository clone that my app references (and is not bundled using a gem) in a /vendor/archive folder. I want this folder synced to my Github repository, but it needlessly bloats my deployment zip.
• On principle: The EB CLI unreasonably relies on .gitignore as its primary method for excluding sensitive and disposable data. If you really want to assemble a unique deployment zip, the CLI will gladly accept a path to a zip that you’ve handcrafted or rolled with another third party tool like Warbler.

Here is the condensed version of the Twitter conversation:

@sarahcassady @aws_eb Thanks for shouting out. Ill move this higher up in the priority queue.

— Nick Humrich (@nhumrich) April 26, 2015

@nhumrich Success! Crazy awesome that you just 'slipped' that in there for me :) I've got some feedback I'll shoot over to you in a DM.

— Sarah Cassady (@sarahcassady) April 29, 2015

How it works

The .ebignore file is not automatically created when you initialize your EB project, but you can add it to override your .gitignore. By default, if an EB project is deployed and .gitignore is present, the CLI will respect those exclusion rules when zipping up the new application version. If a .ebignore is present, the CLI will instead respect those exclusion rules, ignoring .gitignore.

The .ebignore feature is now documented in the AWS Elastic Beanstalk Dev Guide.