I have a number of assets in my rails public/assets directory that I do not want compiled - specifically all the image files I want to use in my ember app. However, I cannot figure out how to get capistrano to deploy them. They are checked in to the public/assets directory but they do not appear in the deployed shared or release directories on my server. In fact I searched the whole capistrano directory tree on my server and the assets are nowhere to be found. I have confirmed that the assets are in git for the branch that capistrano is deploying. Any suggestions would be much appreciated.
I couldn't find a way to configure capistrano / capistrano-rails to allow me to use git source controlled files under public/assets, however, it did work to create an img directory under public and put the images there in git. That avoids the asset compilation process and the md5 hashes for the images and works well with ember.
Related
I've started learning rails and I've already built two apps, one simple blog app and one store app. Now I ran into a term precompile assets when uploading to heroku, can someone explain it to me is that necessary when deploying an app to production, because i've uploaded my store app to heroku without any problems?
Assets is your css + JS. Precompile assets mean that they get joined into single .css and another single .js. file (to load it in one HTTP request). And special mechanism of minifying get applied to both these files (to make them smaller). Rails by default is setup in a way, that it uses average files in dev and compiled files in prod. You can easily change this in configs, but you shouldn't do this unless you really know what you do.
If you want you can compile this files locally running rake assets:precompile and then put it into git. I think that you can disable/enable precompile during heroku deploy in heroku config. But, in general, I would stick with the very defaults.
More info on asset pipeline: http://guides.rubyonrails.org/asset_pipeline.html
Rails has an assets pipeline which consists of Sprockets and the assets helpers.
The assets pipeline will concat and minify your CSS and javascript and takes care of setting the correct paths to images and other assets. This is known as compiling the assets.
In development this is done on the fly for each request which lets you immediately see changes.
In production this would be far to slow so instead the assets should be compiled once at deploy time. Heroku does this automatically for you in a post-commit hook.
Pre-compiling is when you run rake assets:precompile locally and then upload or push the result to a server. This is done if you are deploying to a server without the support for the assets pipeline. For example if the production server does not have a javascript runtime which is required to run uglifier.
It adds tons of noise to the git change history and manually doing anything is a common source of user error. So pretty much it sucks and you only do it if you have to.
I pre-compiled my assets i.e CSS,javascript and fonts files in order to reduce the file size. Using RAILS_ENV=production rake assets:precompile.
I already have compressed assets on the server in the following path:
shared/public/assets
But anyway I went ahead and pre-compiled them again on my local and they got generated inside public/assets folder. I noticed that the compressed files are exactly as same as the ones on server shared/public/assets. But the tester in my team is been testing it on some online tools. And they all say "Your java script files need to be minified." So, would this "minifying" issue be solved if I push these locally pre-compiled assets to production source code?
You should not push locally pre-compiled assets to production source code, no.
Your build process should include precompiling assets for production during a deploy. If you're using Rails 5 then that is already turned on by default. As long as the production environment has a proper environment variable (again, by default, the environment variable 'production' takes care of all these things), the assets will be precompiled.
You say that your compressed files, after running rake assets:precompile, are exactly the same as the ones on the server. That means your javascript should have and should be minified and uglified (again, default for Rails 5). To confirm that's the case, open dev tools in chrome, hard-reload (ctrl+shift+r) and check with JS files are being loaded under "network" tab. If the asset pipeline was used as it should be, you should only see minified and uglified js files here. If you open them up, they should already be minified and uglified. If that's not the case then either the asset pipeline wasn't used for fetching the JS files or your build process has been changed.
If most of these JS files are minified and uglified with - check those which aren't. Is some library being added outside of asset pipeline? Are those files minified?
If all of your JS files are actually minified, then tell your tester to use a different tool ;)
I have several sounds files that are located in public/assets/sounds.
Locally everything works fine, but when I deploy via Capistrano to my ec2 instance, none of those assets make it to the server. I added 'public/assets/sounds' to :linked_dirs in deploy.rb. A directory shows up at 'public/assets/sounds' but none of the mp3s are there. Do I need to manually add all files via :linked_files?
I have it working by just loading the files into the shared/public/assets/sounds directory via ftp, but that doesn't seem like the best use of the Capistrano. I'm also new to Capistrano and could be totally wrong :p
The public/assets directory is reserved for the Rails asset pipeline. You should not place any files there. Here's what I would do:
Remove public/assets/sounds from :linked_dirs.
Choose a different place for the mp3 files, like public/sounds.
Do not add this directory to :linked_dirs.
Recently I upgraded an application from Rails 3 to Rails 4. In the deploy scripts I precompile the assets locally and then rsync them up to the server(s). In Rails 4 the asset pipeline now produces manifest- < random > .json instead of a manifest.yml. Since the manifest files are named differently, this adds multiple manifest.json files to the shared assets directory. The application then picks up the wrong manifest file, and serves old assets.
I have read about various issues related to this in some github pull request threads:
https://github.com/capistrano/capistrano/pull/412
https://github.com/capistrano/capistrano/issues/210
https://github.com/capistrano/capistrano/pull/281
My options seem to be:
Don't share the asset directory.
This would break old clients asking for old resources.
Switch to compiling assets on the servers.
This would add complexity to the server.
Move the manifest file outside of the shared asset directory.
I have since learned that this option was removed in Rails 4.
Are there other solutions to this problem?
I found the best answer after looking at the standard capistrano rails asset precompile task. I added a command to the local precompile task that moves the old asset manifest to the current release as asset_manifest.json. This leaves only one manifest when the new one is uploaded.
run "mv -- #{shared_manifest_path.shellescape} #{current_path.to_s.shellescape}/assets_manifest#{File.extname(shared_manifest_path)}".compact
Moving the manifest-.json to the current_dir as asset_manifest.json allows capistrano to restore the correct manifest file on rollback.
I have several PSD files stored in my images folder. It's nice to keep these files there for development, but I don't want them to be served. Is there a config somewhere that would allow me to prevent a filetype from being precompiled?
Your best bet might be to exclude these files during deployment. For example, with Heroku if you add a .slugignore file to the root of your project you can exclude certain files from being included. This also has the added benefit of decreasing spin up times on Heroku. An example configuration would be:
*.psd
*.pdf
doc
You should be able to do something similar with Capistrano.
Edit:
This post shows how to do something similar for Capistrano deploys:
Excluding files from being deployed with Capistrano while still under version control with Git