The standard place to store non-precompiled public assets in a rails app is in "public/system." Is there any reason for this? I'd like to keep things simple, why shouldn't I just put assets in the "public" folder?
The public/system folder isn't a Rails standard per se or even a documented recommendation. Deployment tools like Capistrano adopted that convention as a suggestion for you to organize user assets that are shared between deployments and shouldn't be in your repository. The idea is symlink public/system to capistrano's shared/system, which is outside of the releases folder.
If you take a look at paperclip's(which is a widely used upload library) docs you'll find:
By default, this location is
:rails_root/public/system/:class/:attachment/:id_partition/:style/:filename. This location was chosen because, on standard Capistrano deployments,
the public/system directory can be symlinked to the app's shared
directory, meaning it survives between deployments.
In your development environment you're supposed to ignore that folder in .gitignore if you're willing to adopt that convention.
Related
I'm converting my RoR app to use capistrano v3. I have a number of configuration file that are generated by ERB. Most of these files, like like /etc/logrotate.d/app_name, are referenced external to my app. So I like the idea of linking them to my shared/config directory. Capistrano supports managing linked files via the linked_files array. So far so good. But, the files to be linked don't technically exist until I run ERB. And capistrano runs :deploy:check:linked_files as the first step of :starting, at which point the files don't exist and the check fails.
So my question is, what's a really good way to handle this? Do I check in empty config files in my config directory, let capistrano link them to shared, and then overwrite them via ERB at a later stage? That doesn't feel good. I can't generate them before the :starting task because on an initial deploy the source tree isn't there yet. Any suggestions?
I wrote a function in Ruby on Rails for uploading a PDF.
The file is uploaded to a folder in public, but every time I deploy to staging or production, the folder on the server seems to become empty.
How to choose the right folder?
In my opinion the easiest way will be to use paperclip
https://github.com/thoughtbot/paperclip
You can easily set folder somewhere like /home/rails/attachments
In documentation for paperclip you have
The files that are assigned as attachments are, by default, placed in the directory specified by the :path option to has_attached_file. By default, this location is :rails_root/public/system/:class/:attachment/:id_partition/:style/:filename. This location was chosen because on standard Capistrano deployments, the public/system directory is symlinked to the app's shared directory, meaning it will survive between deployments. For example, using that :path, you may have a file at /data/myapp/releases/20081229172410/public/system/users/avatar/000/000/013/small/my_pic.png
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
I have a Ruby on Rails project that I've deployed to a PaaS service via GitHub. The Git repo is structured like so:
/ (root)
README
some random files here
src (directory)
a_folder
another_folder
my_rails_app
app (directory)
config (directory)
config.ru
db (directory)
...
Gemfile
...
Rakefile
README
...
As you can see, the Rails app is two directories underneath the root. I suppose I could move it to one file underneath root if necessary, but I definitely need to have other non-Rails files tracked under version control.
But since my Rails app isn't at the root, I'm having trouble using Engine Yard, Heroku, etc... they don't know where to find the Rakefile. I tried creating a Rakefile (https://gist.github.com/245400) and placing it at the root and src directories but it still doesn't work.
Do you know what's going on here or how to fix it?
(As requested ;-D)
If you want to deploy on Heroku/Engine Yard, etc. you might just want to put all those "other folders" within the app directory (e.g. in a folder called supporting_documents or something).
Then you can have those docs under source control AND deploy on Heroku. Also, with Heroku, you'll be able to add those additional documents to the slugignore file (http://devcenter.heroku.com/articles/slug-compiler) so they don't get compiled in the slug.
When Capistrano deploys a Rails app, it creates a shared/ directory to store files that should be shared across releases and not re-exported every time. In my application I have several things in the shared/ directory that rarely change (so they belong there rather than in the application tree), but I'd still like them to be version controlled for the times when they do change.
What is the best way to approach version controlling those files but keeping them separate from the repository Capistrano is exporting from?
The /shared directory is really for un-versioned data. For example, you might store bundled gems so that you don't have to re-install all your gems every release. You can also store you logs there so they don't get overwritten every time you deploy. You can store pid files there so you don't loose the process ids of critical processes during a deploy. You might even store user generated or partially processed data there so that it is not removed during a release. If a file is meant to be versioned and has the chance of changing though, I would recommend keeping it with the rest of your files and out of the shared directory.
That said, you can always also write deploy scripts to pre-populate data in your shared directory, like database configuration files. These scripts will get run on each deploy and can be entirely customized. For example, your database config script might only write the config file if it doesn't already exist.
Another common use of the shared directory is for configuration files. Versioning and source control for configuration files is a very good idea, but should managed in a system configuration management tool. In my environment, I manage code releases with Capistrano and system configuration with Puppet. That way, there is still source control over configuration files, but they are kept distinct from the code deploy process. In turn, the code deploy process is kept independent of system configuration.