I'm using Zonebie to randomize the time zone in my tests. It's all working fine for my rspec tests, but I'm having an issue with my cucumber tests. It works by selecting a random timezone from ActiveSupport and setting Time.zone. I've followed the readme and added Zonebie.set_random_timezone to a support file features/support/zonbie.rb.
If I put a debugger statement in my steps, and I print Time.zone, it produces the correct randomized timezone. However, if I put a debuggger statement in a model function, it prints the default time zone as set up in my config/application.rb.
Is Time.zone being reset somewhere or does the change go out of scope somehow? Any ideas?
NB: I'm also using the Timecop gem if that has any implications.
I found a hack solution, which was to set Time.zone_default instead of Time.zone to the random timezone. I might send a pull request to the zonebie gem maintainers.
Related
Since last couple of months, i see that executing the "bundle install" command for a rails application, source(s) mentioned in gemfile is requested twice when it is supposed to request only once per source mentioned in gemfile.
Can anyone tell me why it is happening and suggest a workaround for it?
In fact bundler does not hit rubygems twice, or at least not for the same reason.
Fetching gem metadata from https://rubygems.org/........
Fetching gem metadata from https://rubygems.org/..
If you look at the queries performed during a "bundle update", here is what you got :
https://rubygems.org:443
http://bundler.rubygems.org/api/v1/dependencies?gems=airbrake,aws-sdk
http://bundler.rubygems.org/api/v1/dependencies?gems=json,activesupport,builder
http://bundler.rubygems.org/api/v1/dependencies?gems=climate_control,rubinius-actor
http://bundler.rubygems.org/api/v1/dependencies?gems=term-ansicolor,gherkin
http://bundler.rubygems.org/api/v1/dependencies?gems=little-plugger,loquacious
http://bundler.rubygems.org/api/v1/dependencies?gems=bones-rcov,bones-rubyforge
http://bundler.rubygems.org/api/v1/dependencies?gems=systemu
http://bundler.rubygems.org/api/v1/dependencies?gems=restclient,spicycode-rcov
I intentionally shortened the URLs for the sake of readability
If you enter this URL in your browser
http://bundler.rubygems.org/api/v1/dependencies.json?gems=airbrake
As you may have noticed, I added the .json extension to have a json output, because the default format is binary
You will see something like this
[
{
"name":"airbrake",
"number":"3.1.8",
"platform":"ruby",
"dependencies":[
["json",">= 0"],
["activesupport",">= 0"],
["builder",">= 0"]
]
},
... (content removed)
]
This response tell us that the airbrake gem depends on json, activesupport and builder. So bundler needs to ask rubygems for more informations about these 3 gems. If you look at the second query above, this is exactly what it does.
http://bundler.rubygems.org/api/v1/dependencies?gems=json,activesupport,builder
This process will take place until all dependencies are resolved. That's why the number of dots may changed depending on the number of "iterations" to resolve all dependencies.
However, I must admit that the reason why the message is shown twice remains unclear. Furthermore, the number of dots (10) does not correspond exactly to the number of queries (9)... I need to investigate a little bit more for that.
I'm using fragment caching in my 3.1. Rails app and have one fragment that isn't expiring and I don't know why. It's a fragment that I want to expire based on time (every hour). I'm on Heroku, using the Memcachier Add-on for my caching. I don't seem to have any other caching issues.
In my app, there are three models: User, Community, and Activity. On the Community#index, there is a fragment that shows Activity by Users in this Community that I want to expire hourly. The calculation, which is a method in the Activity model, works fine - it's just that the fragment is expiring hourly (and refreshing).
In my view, I have:
<% cache("activity_#{community.id}", :expires_in => 1.hour) do %>
<-- content >
<% end %>
I've also tried making it a scheduled task, by adding an expiration for the cache in the User model.
def self.expire_activity
Community.find_each do |community|
ActionController::Base.new.expire_fragment('activity_#{community.id}')
end
end
I tried to follow the answer to this question to determine how to expire the cache from a model, but with this this code, I get the error:
NoMethodError: undefine method 'expire_fragment' for #<Class:0x5ffc3e8>
I was facing a similar issue on Rails 4.2.1. It was caused by a mismatch between the servers set timezone and that of the rails app. Setting both to be the same fixed my issue.
On the server, assuming Ubuntu, as root run this command and follow the prompts:
dpkg-reconfigure tzdata
Within the application.rb config file, be sure that the following line matches the server (default is UTC).
# config.time_zone = 'Central Time (US & Canada)'
To get a list of available time zones for rails, run:
bundle exec rake time:zones:all
I know this is an old question, but is returned high up in google when searching for a solution.
Working on upgrading an application from Ruby 1.8.6/Rails 2.3.5 to Ruby 1.8.7/Rails3.0.11.
In application.rb, config statements have been moved (from environment.rb) into the:
module AppName
class Application < Rails::Application
...
end
end
block, including the statement:
config.time_zone = 'Eastern Time (US & Canada)'
In the old environment.rb file, there was also some code for initialization of some constants, which i've moved into application.rb. I've tried it after the module/class block (as it was before) and within it, but the following statement:
Time.zone.parse(external_config_date)
is producing this error:
config/application.rb:49: undefined method `parse' for nil:NilClass (NoMethodError)
I'm a little baffled by this (as often happens with Rails date/times :-/); mostly it looks like Time.zone is an acceptable way to access the default time zone, but i've also seen it said that 'zone' is an instance method of Time instead of a class method.
Any insight on this (or thoughts on how to troubleshoot further) much appreciated!
It looks like moving the extra config code from environment.rb into application.rb was my mistake here. 'Time.zone.parse' appears to be a Rails add-on, and it hadn't been enabled in application.rb yet. Moving the config code back to the bottom of environment.rb, after the line
AppName::Application.initialize!
got it working.
I'm seeing an error in some integration specs, using rspec, capybara, capybara-webkit and timecop.
Capybara::FrozenInTime:
time appears to be frozen, Capybara does not work with libraries which freeze time, consider using time travelling instead
The only gem that I know that freezes time is Timecop, but I'm not using it in the test case that fails.
Since the error occurs only sometimes I can't even know if its gone or not after changing something.
The end of the error message holds the solution:
consider using time travelling instead
Just change Timecop.freeze to Timecop.travel. Timecop.freeze breaks Capybara's auto-wait feature.
In addition, I would call Timecop.return in an after block, as it will be associated with the most recent travel block:
after :each do
Timecop.return
end
The solution I found was to add
before :each do
Timecop.return
end
in spec_helper.rb.
This way we garantee that the time is not frozen before each test, although the only ones that have this problem are the ones executed in a webdriver different from rack-test. In my case capybara-webkit.
I want to show variable values in console while my scenario performing. Cause I don`t know how to know it in another way.
logger.debug(whatever)
puts whatever
binding.pry # Links below
Pry and Rails and Pry
Or ruby debugger, or debug inside an IDE, or...