I use simplecov to measure coverage for my Rails 4.0.11 app. I use Ruby 2.0.0. I noticed that some subfolders of /app are ignored by simplecov and I can't figure out why.
test_helper.rb:
require 'simplecov'
SimpleCov.start 'rails'
ENV["RAILS_ENV"] = "test"
require File.expand_path('../../config/environment', __FILE__)
I have tried upgrading to Ruby 2.1 after reading some posts that that might help, but still some subfolders are being ignored. I also tried to move the SimpleCov.start into a .simplecov file at the root of my project, but the problem persists. I also tried to remove the rails configuration and add filters and groups myself, but the ignored ones just turn up empty.
Folder like /mailers, /serializers, /presenters are all ignored. It does pick up on /models and /controllers.
I had the same issue. in your rails environments/test.rb make config.eager_load = true. this will load every ruby files while app booting.
Related
I accidentally removed a folder (it might be db or lib folder), but immediately find out about it and put it back on same place it was (I am using RubyMine so I did cmd+z (on Mac)).
This caused so I got error: Migrations are pending. To resolve this issue, run rake db:migrate and I ran rake db:migrate and as I could see It ran all migrations files (from first migration file) and migrated all my tables as it was newly added and removed all my records.
Since I have version control, I rested the branch to previous branch but still have the same issue.
I have doubled checked all the folders and files and everything is where is needs to be (I think) but for some reason it needs to run all migration once again.
I am currently in Development ENV and don't know if it is going to run migration when deployed with capistrano gem to Production ENV and remove all my records in my Production ENV.
In my schema.rb my version is: ActiveRecord::Schema.define(version: 20161108160645) and 20161108160645 is the same number as my last migration file 20161108160645_add_name_avatar_to_comments.rb
What can I do to fix everything back to normal?
Rails version: 4.2.4
Ruby version: 2.2.1
db folder was removed and that causes all issues with pending migration.
Way to do is:
1) Remove project folder
2) With SourceTree clone the project
3) Run rake db:migrate to migrate all tables
I'm using git to version control a Django 1.7 + Django CMS 3.0.6 project.
In the course of building various apps etc I'm ending up with a lot of migration files. The migration files are currently included in my git repo.
Thus far I have been trying to avoid including the virtual env files in my repo directly as it seems rather messy and redundant. Instead I have thus far been including a pip requirements file in the repo and using that to recreate the virtual env when needed.
However, I have recently discovered that choosing to include the migration files in the repo seems to require including all of the virtual env files in the repo as well. I say this because upon deploying my project to a production server and trying to run any of the db commands (syncdb, makemigrations or migrate) via python manage.py I get the error:
KeyError: u"Migration image_gallery.0001_initial dependencies reference nonexistent parent node (u'cms', u'0004_auto_20141108_1256')"
whereas such error does not occur on my local machine, even after deleting the database.
I tracked the source of this error down to the fact that the virtual env on my local machine has a reference to '0004_auto_20141108_1256' (inside the django-cms package - it appears some cms migration info is recorded directly inside the virtual env directory itself) while that of the production environment does not - as the production venv is create thorough a pip requirements file. Therefore, the two virtual envs do not exactly match, even though all third party libs are the same. Currently I am not including the venv in my git repo.
So as I see it I have two options:
1. include the virtual env in my git repo
2. drop the migration files from git
Which option is better and why - or is there a third even better way?
The downside to #1 is unnecessary bloat. The downside to option #2 is one loses the migration history, something one might potentially want to keep.
You never commit the virtual env, it defeats the purpose; you just add unnecessary content to git.
Instead, freeze the requirements and commit the file:
pip freeze > requirements.txt
Install the packages on the server:
pip install -r requirements.txt
The problem is in my django settings.py file:
MIGRATION_MODULES = {
'cms': 'cms.migrations_django',
'menus': 'menus.migrations_django',
'djangocms_file': 'djangocms_file.migrations_django',
...
}
I had to introduce the above to get django-cms 3.0.6 to work with django 1.7, a consequence of the fact that migrations in django 1.7 are no longer done with South, as django 1.7 now has it's own migration system, while cms 3.0.6. still expects migrations to be managed by South by default.
However, the effect of the above config is to store migrations in the above described paths which in my case pointed straight to the virtual env. Thus migration info was getting stored within the virtual env dir, leading to problems in deploying to production.
To fix this I modified my project directory structure to include a folder called "migrations":
myproject/manage.py
myproject/migrations/
myproject/myproject/
...
And modified the config to be:
MIGRATION_MODULES = {
'cms': 'migrations.cms.migrations_django',
'menus': 'migrations.menus.migrations_django',
'djangocms_file': 'migrations.djangocms_file.migrations_django',
...
}
This has the effect of now storing all migration files in the django project itself (and by extension the git repo). As migration info is no longer in the virtual env directory, there is no longer any reason to consider the rather unattractive possibility of including the virtual env in the repo.
I have just deployed a new app on heroku for the first time.
Unlike many others I had no troubles precompiling the assets. They are neatly precompiled and placed in
public/assets. I verified this in heroku bash terminal.
However when I open the project web page none of my assets are served. I verified that the hash to avoid cache stuff was correct.
I have in my application.rb added config.serve_static_assets = true but it made no difference.
There public/assets/manifest.json (pointing to the right files) but no yml and I think I read somewhere about a manifest.yml. Could this be the problem?
Any advice on how to debug this? Or what might be wrong.
Edit
In answer to the comment an example:
There is a file in the heroku app (checked with heroku bash)
public/assets/application-7744776478cb6ee3a23dd79bfcc293bd.css
my browser asks the heroku app for:
´assets/application-7744776478cb6ee3a23dd79bfcc293bd.css´
and the heroku app answers with 404 file not found.
I solved the issue by adding the gem rails_12factor
suggested in: heroku assets not found 404
Rails 4.1.1 production installation using Apache/Passenger configured to run rails app in a subdirectory "/myapp" instead of the root of the site.
All links in the app work fine, but in production references to assets in SCSS file, for example
background-image: image-url('logo.png');
get compiled to:
background-image: url("/assets/logo-<hash>.png");
instead of:
background-image: url("/myapp/assets/logo-<hash>.png");
I tried doing something like this when precompiling assets:
RAILS_ENV=production RAILS_RELATIVE_URL_ROOT=/myapp rake assets:precompile
but that had no effect.
I also tried setting config.relative_url_root in the config/environments/production.env file, with no luck.
The Rails guides say to set config.action_controller.relative_url_root, but that results in a missing method error.
I eventually gave up and embedded the image in the CSS file by using:
background-image: asset-data-url('logo.png');
which works, but only by avoiding the subdirectory problem altogether.
I know Rails makes you pay for not following conventions, but having an app in a subdirectory is not exactly outlandish.
I've seem all kinds of posts on this problem, but it's hard to get a straight answer. It seems to have been fixed a few times for earlier versions of Rails, but it's not clear if the fixes ever got into the standard Rails distribution.
In our case, we were able to make two changes, which seem to be working for us in Rails 4.1.6 :
1) In application.rb, assume there is a module named "MyAppName < Rails::Application". In here, we have
config.relative_url_root = "/myapp"
2) In config.ru:
map MyAppName::Application.config.relative_url_root || "/" do
run Rails.application
end
Without the config.ru update, things don't work properly.
After adding the jquery-ui-rails gem to another app deployed in a subdirectory, I had the same problem with the assets referred to by the built-in CSS for jQuery UI. I refused to modify the 3rd-party CSS files just to fix this problem, especially since Rails seems to be handling all paths (other than asset paths) correctly out of the box.
After pulling my hair out for some time, I don't know what prompted me to re-run the rake assets:precompile task exactly as given here. To my complete surprise, everything worked perfectly, both my own image URLs and jQuery UI's.
What made the difference? If I call the rake script from the app's bin folder as shown below, all the asset URLs are built incorrectly, without the subdirectory.
RAILS_ENV=production RAILS_RELATIVE_URL_ROOT=/myapp bin/rake assets:precompile
If instead I run rake via bundle exec, as follows, all the asset paths are generated correctly, including the subdirectory.
RAILS_RELATIVE_URL_ROOT=/myapp RAILS_ENV=production bundle exec rake assets:precompile
As to why this is happening, I can only conclude that running bin/rake does not load the right gems.
I wanted to start playing around with Django again (I'm not an expert in Python/Django, but I can make nice things work tho). I used Mezzanine once just to see how it worked. The 'mezzanine-project myproject' command worked like a charm as I had a nice small app running quickly. So, today I downloaded the new Mezzanine 1.3 along with Django 1.4.3 and all its dependencies (pillow, pytz, html5lib, etc) and tried to create another project so I could now work on it in a more consistent manner for personal purposes.
For my surprise, when I ran the server, I got lots of 404 errors pointing to missing /static/ files. Also, after creating the database (with manage.py createdb command), the only thing created was the static folder containing only the pictures of the predefined gallery that come along with Mezzanine. Also, there is no Log in or signup buttons as well.
I've tried making a clean install of all Python and its site-packages with the same result. I also tried copying/pasting the folders containing missing files from the /site-packages/mezzanine folder into my project, but the result was just reducing the number of 404 messages.
I've been doing an extensive research on this issue (with no luck but maybe because of the release being recent?) and even trying to contact someone on the Mezzanine IRC channel with no success.
I hope I'm not missing something silly. Do I have to change anything (note that I'm ok with the old mezzanine default settings) in my settings.py or in a specific file before running manage.py createdb command?
For the record: before running createdb, The only thing I edited was settings.py and changed the database parameters to make it work with my MySQL Server and commenting the local_settings configuration as I do not need it.
Some parameters that could be of help:
PROJECT_ROOT = os.path.dirname(os.path.abspath(__file__))
STATIC_URL = '/static/'
STATIC_ROOT = os.path.join(PROJECT_ROOT, STATIC_URL.strip("/"))
By default, DEBUG is set to False in settings.py, and DEBUG is set to True in local_setting.py
Given that, if you just commented out importing local_settings.py, DEBUG would be False.
Django's development server won't serve static files when DEBUG is set to False, see the staticfiles section of the Django docs for more details.