AWS Customer Support WinSarah 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
.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
.gitignoreor 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/archivefolder. I want this folder synced to my Github repository, but it needlessly bloats my deployment zip.
- On principle: The EB CLI unreasonably relies on
.gitignoreas 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:
@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
.ebignore file is not automatically created when you initialize your EB project, but you can add it to override your
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.
.ebignore is present, the CLI will instead respect those exclusion rules, ignoring
.ebignore feature is now documented in the AWS Elastic Beanstalk Dev Guide.