Last night I think I did something that hosed my rails development environment, and I'm unable to reverse what I did.
I migrated an update to production and was having some trouble precompiling a stylesheet so I backed out the changes and decided to attempt a precompile on my development machine.
Long story short, the precompile failed on my development machine (local) but when I tried to bring up my test system I got this error:
Sprockets::CircularDependencyError in Devise/sessions#new
/app/assets/stylesheets/application.css has already been required
I'm certain this has something to do with my attempted precompile, even though it failed because prior to that everything was working fine.
I tried to do precompile:clear because I read somewhere that will reverse/delete the precompile.
Am I missing something here? Does a precompile change configuration files somewhere that I need to manually reset?
This is rails 3.1 running on Ubuntu 11.10.
This is happening because your application.css.scss is most likely requiring a css file that's requiring application.css.scss. You'll want to go through app/assets/stylesheets and check the headers of application.css.scss, and then the headers of all the files it requires to make sure that none of them reference application.css.scss.
I fixed it by creating an application.css.scss and by importing each of my files in there, like this:
#import "backend.css.scss";
#import "frontend.css.scss";
then it worked
Related
In development mode, all looks great. But when I switch over to production, bootstrap isn't found. When I look at the logs, I see errors like:
ActionController::RoutingError (No route matches [GET] "/packs/js/application-2a5806e943e281221741.js"):
This is true for both CSS and JS. When I look inside public/packs the files do exist in the corresponding subdirectory (js for the .js file, etc). So, webpacker is did it's job but puma isn't finding it. Any ideas? This is an old rails app that was migrated up several versions of rails, so I'm sure there is something I missed when tying everything together.
To expand on Tenzin's comment which I believe is the correct answer to the issue, Rails in development will always re-render assets and serve them. This is slow, but useful for seeing quick changes while developing.
When we want to deploy to production, the issue is Rails begins to serve static files which means that the server is no longer going to render them on every request. It will render them once and serve them forever. With webpacker, you can find the places these assets are served in webpacker.yml
public_root_path: public
public_output_path: packs
So if you are deploying or trying to run production locally, first be sure to compile your assets for production so these static files are created.
rake assets:precompile RAILS_ENV=production
Then make sure that wherever the server is running it has an ENV variable RAILS_SERVE_STATIC_FILES set to anything. As you can see from production.rb,
config.public_file_server.enabled = ENV['RAILS_SERVE_STATIC_FILES'].present?
Is simply checking if this variable is present. If it is then it will not re-render as we discussed and it will look for the static files shown in webpacker.yml.
As another small note, if you are using something like a React UI or Bootstrap and the CSS is missing, be sure that you are importing the CSS according to the library's documentation.
For example, in Bootstrap, you will need to create an application.scss file in app/javascript/packs/stylesheets (really wherever in the /javascript folder) and import that in /javascript/packs/application.js.
In application.scss you'll want to
import "~bootstrap/scss/bootstrap"
This is of course after you have added Bootstrap to your package.json with something like
yarn add bootstrap
Essentially I have a basic app that I would like to use as base for my other projects.
I ran git clone git#site.org:user/app.git newfolder
But when I run my rails app rails s I get the following error:
Migrations are pending; run 'rake db:migrate RAILS_ENV=development' to resolve this issue.
So I run rake db:migrate and start the app again, getting the following error:
I have a sneaking suspicion that it has something to do with the app name as asked in this question but I noticed the solution was provided for Rails 3 and the GitHub project hasn't been updated in two years.
Essentially, I think I have a solution (renaming the app) but I don't know how to do that. However, I may be wrong and I don't know why I am getting this error?
You are getting this error because, one of the css files you are requiring in your application.css is requiring application.css. Go through all the file in your app/assets/stylesheets and make sure that none of the file that is required in application.css is requiring application.css.
I'm having an odd and somewhat confusing problem.
I am trying to install Redmine on Heroku. I followed the instructions and well lets say it hasn't been a smooth ride.
I am now trying to do the db:migrate process. (I had to edit all the cruft in the application.rb to get this far, and don't know yet where this will lead.)
In doing the migration however, I get the message
Plugins in vendor/plugins (/app/vendor/plugins) are no longer allowed. Please, put your Redmine plugins in the `plugins` directory at the root of your Redmine directory (/app/plugins)
Through StackOverflow and some other sites, I have found where this message is generated (environment.rb) and have removed the code that generates it.
However, when I push to Heroku and try the migrate again, the same message reoccurs.
I have tried cloning the Heroku repo/app down to a test directory and when I check the environment.rb file, the code is not there, however if I try the migrate (or any rake task for that matter) the message still occurs. Even from the test directory.
I've looked for the same message in other parts of the code, but haven't found it yet. Have I missed something?
There's one of two things at play here
You're not fixing the problem in your code - running it locally in production mode will show this
OR
You're not pushing your code to Heroku correctly. Are you developing on the master branch? Are you developing in a feature branch? If so, are you pushing that branch into master on Heroku? (git push heroku feature_branch:master)
Okay I figured out what was happening. It's amazing what a good nights sleep can accomplish!
It turns out the cruft in the application.rb file that I mentioned earlier was basically the other files in the config directory appended to app.rb. These included the yml files along with other files like environment.rb and routes.rb. And in amongst this crap was the plugin panic code I had deleted from environment.rb
(It finally came to light when running rake after some changes told me that the application was already initialised!)
So I deleted all this appended nonsense from application.rb and viola! working.
I have no idea why this was done this way as redmine works fine (so far) without it.
The problem in a nutshell is that in development mode we'd make changes to CSS or JS files but would always get cached/old versions of these files. Nothing I did had any effect. I checked configuration dozens of times and tried every combination of config values but always kept getting the same results: stale/cached files. I had to actually run in production mode and restart the server after every change to test.
I spent days tearing my hair out over this issue, looked at dozens of stackoverflow questions on the asset pipeline but never found one that addressed it so I thought I'd post it here for posterity.
We use Heroku and precompile our assets because Heroku fails to precompile for us (we also use devise which apparently is the cause of the heroku precompilation failure). So in order to push our precompiled assets up to Heroku we have to check them in to git.
Here's the problem.
When we upgraded to Rails 3.1.1 asset precompilation produced files both with and without the MD5 hash in the name. I didn't think much of this and went ahead and checked all these files in so I could push to heroku. Sometime later I noticed the problem with cached results in development mode. The precompiled and checked in assets without the MD5 hashes were being served from /public/assets as static files which prevented us from seeing any changes we were making in /app/assets.
After finally realizing this I ran git rm /public/assets and everything works again. So the takeaway is: Be careful checking assets into git!
To turn this into a question: how do others do this? Am I missing something obvious? What I'd really like is for Heroku to precompile my assets for me but it is failing with a db connection error that I gather is because of devise. I had hoped Rails 3.1.1 fixed this but it didn't.
Have you checked out this devise issue on github? Specifically Jose Valim says
Rails 3.1.1 final has a method called
config.assets.initialize_on_precompile. If you set it to false, you
should be good but it won't allow you to access model information on
your assets (which you probably shouldn't anyway).
Maybe this will allow the precompile to happen on Heroku for you.
The reason the asset precompilation does not work could well be, that the Heroku ENV vars are not present on slug compilation (deploy) as stated here:
http://devcenter.heroku.com/articles/rails31_heroku_cedar
There is an (experimental) way to enable the ENV vars during deploy for exactly this reason, find information here:
http://devcenter.heroku.com/articles/labs-user-env-compile
Hope this helps.
Check this guide from Heroku. It outlines the 3 ways to deploy Rails 3.1 apps. Two of these do not required local precompilation.
I'm just getting acquainted with Rails 3.1, and I burned some time updating an old project and trying to work out how the new asset pipeline behaves in development mode versus production.
The default config.assets.precompile setting blesses only application.css and application.js, with the intention that everything should be served as a single stylesheet and a single javascript file.
Obviously there are situations when we don't want that, so we can add items to the list in that config variable...
Here's the situation I ran into with my sandbox project when going to production:
Browsed the site in development, saw that everything was working. The assets were linked as separate files and the site displayed correctly.
Uploaded the site to my server, and tried to get it working in production. The first error was saying that "ie.css" (a conditional stylesheet) isn't precompiled. (I was in Safari and this stylesheet wouldn't even be downloaded: the error was raised from the stylesheet_link_tag helper before rendering the page.)
Ran rake assets:precompile and tried again.
Added the offending item to config.assets.precompile and tried again.
Kicked the error down the curb until it hit another asset error.
GOTO 3.
Not knowing how to address this, I went around in circles a few times until I thought I got all the assets and the site was rendering in production. Then I tried it in MSIE and hit another error 500: "belated_png_fix.js" was being conditionally loaded, and it didn't crop up until then.
So my question is, other than trial and error or a heavy dependence on integration testing, how can I predict that my site isn't going to bomb out when the asset pipeline discovers that some stylesheet or javascript wasn't added to the precompile list?
I'm also curious why a missing stylesheet asset should cause the whole page to error 500 instead of just compiling it on-demand or serving a 404 when that asset is requested. Is this a deliberate design to "fail early"?
I've just released a gem called assets_precompile_enforcer, which ensures that developers won't forget to add assets to config.assets.precompile while they are developing. An exception will be raised if you include an asset via javascript_include_tag or stylesheet_link_tag, and it doesn't match a filter in config.assets.precompile.
This means that asset errors will be caught during development, instead of being discovered after deploying to production.
I had similar problems with rails 3.1 as well. The best thing you could do is to install capistrano multi stage and get a staging server.
If for any reasons this is not possible, install a virtual machine on your computer and try to replicate your servers environment.
Continuous deployment is a great thing, and you should get to the point where it is so simple that it really isn't that painful anyway. That being said, config.assets.precompile can take regexs, so how about you come up with a standard for top level sprockets "manifest" files, or a standard sub folder for things that will not be bundled up? (note that I haven't actually tried this yet...)
This may be overkill, but this works for me (it gives me clean, compiled assets). I have this in my .bash_profile file.
alias ggo='bundle exec rake assets:clean && bundle exec rake assets:precompile && git add . && git commit -m "precompile" && git push origin master && cap deploy'
and this in my config/environments/production.rb (forces production to compile when needed; shouldn't be a need to if I remember to run "ggo" first):
config.assets.compile = true
So, my workflow is:
1. code
2. git add & git commit
3. if I touched CSS/SASS/JS/CoffeeScript files, I run ggo. Otherwise, I do a normal cap deploy.