I am stumped. I am not sure how to locate the source of my issues. Here is the error I get:
> bundle exec rspec spec
ThemeMaintainer
should have tests (FAILED - 1)
Failures:
1) ThemeMaintainer should have tests
Failure/Error: Unable to find matching line from backtrace
TypeError:
wrong argument type Class (expected Module)
# /Users/tj/.rvm/gems/ruby-2.1.3#global/ruby/2.1.0/gems/actionpack-4.0.12/lib/abstract_controller/helpers.rb:170:in `include'
# /Users/tj/.rvm/gems/ruby-2.1.3#global/ruby/2.1.0/gems/actionpack-4.0.12/lib/abstract_controller/helpers.rb:170:in `block in add_template_helper'
# /Users/tj/.rvm/gems/ruby-2.1.3#global/ruby/2.1.0/gems/actionpack-4.0.12/lib/abstract_controller/helpers.rb:170:in `module_eval'
# /Users/tj/.rvm/gems/ruby-2.1.3#global/ruby/2.1.0/gems/actionpack-4.0.12/lib/abstract_controller/helpers.rb:170:in `add_template_helper'
# /Users/tj/.rvm/gems/ruby-2.1.3#global/ruby/2.1.0/gems/actionpack-4.0.12/lib/abstract_controller/helpers.rb:95:in `block in helper'
# /Users/tj/.rvm/gems/ruby-2.1.3#global/ruby/2.1.0/gems/actionpack-4.0.12/lib/abstract_controller/helpers.rb:94:in `each'
# /Users/tj/.rvm/gems/ruby-2.1.3#global/ruby/2.1.0/gems/actionpack-4.0.12/lib/abstract_controller/helpers.rb:94:in `helper'
# /Users/tj/.rvm/gems/ruby-2.1.3#global/ruby/2.1.0/gems/actionpack-4.0.12/lib/action_view/test_case.rb:93:in `include_helper_modules!'
# /Users/tj/.rvm/gems/ruby-2.1.3#global/ruby/2.1.0/gems/actionpack-4.0.12/lib/action_view/test_case.rb:86:in `new'
Finished in 0.0017 seconds (files took 13.66 seconds to load)
1 example, 1 failure
Failed examples:
rspec ./spec/helpers/theme_maintainer_spec.rb:4 # ThemeMaintainer should have tests
Top 1 slowest examples (0.00001 seconds, 0.8% of total time):
ThemeMaintainer should have tests
0.00001 seconds ./spec/helpers/theme_maintainer_spec.rb:4
Randomized with seed 27022
Coverage report generated for RSpec to /Users/tj/projects/AOT/aotv2/coverage. 9272 / 22617 LOC (41.0%) covered.
/Users/tj/.rvm/gems/ruby-2.1.3#global/ruby/2.1.0/gems/actionpack-4.0.12/lib/abstract_controller/helpers.rb:170:in `include': wrong argument type Class (expected Module) (TypeError)
from /Users/tj/.rvm/gems/ruby-2.1.3#global/ruby/2.1.0/gems/actionpack-4.0.12/lib/abstract_controller/helpers.rb:170:in `block in add_template_helper'
from /Users/tj/.rvm/gems/ruby-2.1.3#global/ruby/2.1.0/gems/actionpack-4.0.12/lib/abstract_controller/helpers.rb:170:in `module_eval'
from /Users/tj/.rvm/gems/ruby-2.1.3#global/ruby/2.1.0/gems/actionpack-4.0.12/lib/abstract_controller/helpers.rb:170:in `add_template_helper'
from /Users/tj/.rvm/gems/ruby-2.1.3#global/ruby/2.1.0/gems/actionpack-4.0.12/lib/abstract_controller/helpers.rb:95:in `block in helper'
from /Users/tj/.rvm/gems/ruby-2.1.3#global/ruby/2.1.0/gems/actionpack-4.0.12/lib/abstract_controller/helpers.rb:94:in `each'
from /Users/tj/.rvm/gems/ruby-2.1.3#global/ruby/2.1.0/gems/actionpack-4.0.12/lib/abstract_controller/helpers.rb:94:in `helper'
from /Users/tj/.rvm/gems/ruby-2.1.3#global/ruby/2.1.0/gems/actionpack-4.0.12/lib/action_view/test_case.rb:93:in `include_helper_modules!'
from /Users/tj/.rvm/gems/ruby-2.1.3#global/ruby/2.1.0/gems/actionpack-4.0.12/lib/action_view/test_case.rb:86:in `new'
from /Users/tj/.rvm/rubies/ruby-2.1.3/lib/ruby/gems/2.1.0/ruby/2.1.0/gems/rspec-core-3.1.4/lib/rspec/core/example_group.rb:472:in `run'
from /Users/tj/.rvm/rubies/ruby-2.1.3/lib/ruby/gems/2.1.0/ruby/2.1.0/gems/rspec-core-3.1.4/lib/rspec/core/runner.rb:111:in `block (2 levels) in run_specs'
from /Users/tj/.rvm/rubies/ruby-2.1.3/lib/ruby/gems/2.1.0/ruby/2.1.0/gems/rspec-core-3.1.4/lib/rspec/core/runner.rb:111:in `map'
from /Users/tj/.rvm/rubies/ruby-2.1.3/lib/ruby/gems/2.1.0/ruby/2.1.0/gems/rspec-core-3.1.4/lib/rspec/core/runner.rb:111:in `block in run_specs'
from /Users/tj/.rvm/rubies/ruby-2.1.3/lib/ruby/gems/2.1.0/ruby/2.1.0/gems/rspec-core-3.1.4/lib/rspec/core/reporter.rb:53:in `report'
from /Users/tj/.rvm/rubies/ruby-2.1.3/lib/ruby/gems/2.1.0/ruby/2.1.0/gems/rspec-core-3.1.4/lib/rspec/core/runner.rb:107:in `run_specs'
from /Users/tj/.rvm/rubies/ruby-2.1.3/lib/ruby/gems/2.1.0/ruby/2.1.0/gems/rspec-core-3.1.4/lib/rspec/core/runner.rb:85:in `run'
from /Users/tj/.rvm/rubies/ruby-2.1.3/lib/ruby/gems/2.1.0/ruby/2.1.0/gems/rspec-core-3.1.4/lib/rspec/core/runner.rb:69:in `run'
from /Users/tj/.rvm/rubies/ruby-2.1.3/lib/ruby/gems/2.1.0/ruby/2.1.0/gems/rspec-core-3.1.4/lib/rspec/core/runner.rb:37:in `invoke'
from /Users/tj/.rvm/gems/ruby-2.1.3#global/ruby/2.1.0/gems/rspec-core-3.1.4/exe/rspec:4:in `<top (required)>'
from /Users/tj/.rvm/gems/ruby-2.1.3#global/ruby/2.1.0/bin/rspec:23:in `load'
from /Users/tj/.rvm/gems/ruby-2.1.3#global/ruby/2.1.0/bin/rspec:23:in `<main>'
and here is the spec
require 'spec_helper.rb'
RSpec.describe ThemeMaintainer do
it 'should have tests'
end
Everytime I run rspec spec I get an error right away on a different spec (it is randomizing sequence of tests). Obviously? there is nothing wrong with the ThemeMaintainer spec. And each one that I get an error on I can easily pass when run by itself.
So my question is how do I find the spec that is really failing?
I have 8 dirs under specs. I run them rspec spec/<dir> 8 individual runs and all runs fine. Only when I run rspec spec for the whole app do I get the error. Stacktrace is ALWAYS the same. Error is always the same.
I could use some guidance on how to diagnose.
Apparently as was recommended in a Github issue response, config.infer_spec_type_from_file_location! should not be being used (as in turn it off in RSpec.configure) and that solves the problem.
I am still not sure why having had it on for 2 years and not having any issue thus far that it now failed.
You didn't close the block.
require 'spec_helper.rb'
RSpec.describe ThemeMaintainer do
it 'should have tests' do
end
end
Related
It shows wrong number of arguments but I am passing 3 arguments
ScannerWorker.perform_async('bob1','bob2',5)
Here sidekiq worker code
class ScannerWorker
include Sidekiq::Worker
def perform(bob1, bob2, bob3)
puts bob1
end
end
sidekiq version:- 4.2.7
rails 4.2.6
Redis server v=3.0.7
Sidekiq Error:-
2017-01-03T06:29:43.007Z 9547 TID-itjjk WARN: ArgumentError: wrong number of arguments (given 0, expected 2..3)
2017-01-03T06:29:43.007Z 9547 TID-itjjk WARN: /home/smk/14.04/rails/projects/myappname/app/workers/scanner_worker.rb:5:in `test'
/home/smk/14.04/rails/projects/myappname/app/workers/scanner_worker.rb:5:in `perform'
/home/smk/14.04/rails/projects/myappname/vendor/bundle/gems/sidekiq-4.2.7/lib/sidekiq/processor.rb:158:in `execute_job'
/home/smk/14.04/rails/projects/myappname/vendor/bundle/gems/sidekiq-4.2.7/lib/sidekiq/processor.rb:138:in `block (4 levels) in process'
/home/smk/14.04/rails/projects/myappname/vendor/bundle/gems/sidekiq-4.2.7/lib/sidekiq.rb:36:in `block in <module:Sidekiq>'
/home/smk/14.04/rails/projects/myappname/vendor/bundle/gems/sidekiq-4.2.7/lib/sidekiq/processor.rb:133:in `block (3 levels) in process'
/home/smk/14.04/rails/projects/myappname/vendor/bundle/gems/sidekiq-4.2.7/lib/sidekiq/middleware/chain.rb:128:in `block in invoke'
/home/smk/14.04/rails/projects/myappname/vendor/bundle/gems/sidekiq-4.2.7/lib/sidekiq/middleware/server/active_record.rb:6:in `call'
/home/smk/14.04/rails/projects/myappname/vendor/bundle/gems/sidekiq-4.2.7/lib/sidekiq/middleware/chain.rb:130:in `block in invoke'
/home/smk/14.04/rails/projects/myappname/vendor/bundle/gems/sidekiq-4.2.7/lib/sidekiq/middleware/server/retry_jobs.rb:74:in `call'
/home/smk/14.04/rails/projects/myappname/vendor/bundle/gems/sidekiq-4.2.7/lib/sidekiq/middleware/chain.rb:130:in `block in invoke'
/home/smk/14.04/rails/projects/myappname/vendor/bundle/gems/sidekiq-4.2.7/lib/sidekiq/middleware/server/logging.rb:11:in `block in call'
/home/smk/14.04/rails/projects/myappname/vendor/bundle/gems/sidekiq-4.2.7/lib/sidekiq/logging.rb:32:in `with_context'
/home/smk/14.04/rails/projects/myappname/vendor/bundle/gems/sidekiq-4.2.7/lib/sidekiq/middleware/server/logging.rb:7:in `call'
/home/smk/14.04/rails/projects/myappname/vendor/bundle/gems/sidekiq-4.2.7/lib/sidekiq/middleware/chain.rb:130:in `block in invoke'
/home/smk/14.04/rails/projects/myappname/vendor/bundle/gems/sidekiq-4.2.7/lib/sidekiq/middleware/chain.rb:133:in `invoke'
/home/smk/14.04/rails/projects/myappname/vendor/bundle/gems/sidekiq-4.2.7/lib/sidekiq/processor.rb:132:in `block (2 levels) in process'
/home/smk/14.04/rails/projects/myappname/vendor/bundle/gems/sidekiq-4.2.7/lib/sidekiq/processor.rb:174:in `stats'
/home/smk/14.04/rails/projects/myappname/vendor/bundle/gems/sidekiq-4.2.7/lib/sidekiq/processor.rb:131:in `block in process'
/home/smk/14.04/rails/projects/myappname/vendor/bundle/gems/sidekiq-4.2.7/lib/sidekiq.rb:35:in `block in <module:Sidekiq>'
/home/smk/14.04/rails/projects/myappname/vendor/bundle/gems/sidekiq-4.2.7/lib/sidekiq/processor.rb:126:in `process'
/home/smk/14.04/rails/projects/myappname/vendor/bundle/gems/sidekiq-4.2.7/lib/sidekiq/processor.rb:82:in `process_one'
/home/smk/14.04/rails/projects/myappname/vendor/bundle/gems/sidekiq-4.2.7/lib/sidekiq/processor.rb:70:in `run'
/home/smk/14.04/rails/projects/myappname/vendor/bundle/gems/sidekiq-4.2.7/lib/sidekiq/util.rb:17:in `watchdog'
/home/smk/14.04/rails/projects/myappname/vendor/bundle/gems/sidekiq-4.2.7/lib/sidekiq/util.rb:25:in `block in safe_thread'
You need to restart Sidekiq. Live code reloading only works with Sidekiq 4.2+ running Rails 5.0+.
Follow this steps
* Mention the sidekiq version in gemfile
* kill the sidekiq process and restart the sidekiq
You need to restart Sidekiq
To Start:
$ bundle exec sidekiq
To Run in the background:
$ bundle exec sidekiq -d -P tmp/sidekiq.pid -L log/sidekiq.log
where -d demonize, -P pid file, -L log file.
Stop:
$ bundle exec sidekiqctl stop tmp/sidekiq.pid 0
Sidekiq shut down gracefully.
where 0 is number of seconds to wait until Sidekiq exits.
worth noting. I've been working on a similar issue.
SomeWorker.perform_async(#user.id)
class SomeWorker
include Sidekiq::Worker
def perform(user_id)
puts "{user_id}"
end
end
unsure exactly why i was getting the arguments error. Maybe it was an because of an instance variable, maybe a rails bug.
Nevertheless, I receated the worker using
$rails g sidekiq:worker SomeWorker
and saw this *.
class SomeWorker
include Sidekiq::Worker
def perform(*args)
puts #some thing
end
end
by adding the astrix everything worked perfectly.
quick answer:
class SomeWorker
include Sidekiq::Worker
def perform(*user_id)
puts #some thing
end
end
I have the following hmtl code. li id is increasing sequentially, and I want to generate regex so as to use in xpath but is not working:
irb#1(main):044:0* find(:xpath, "//li[#id = 'divPictureAndPrices_productListItem1']")
=> #<Capybara::Node::Element tag="li" path="/html/body/div[2]/div[7]/div[2]/div/div[3]/ol/li[2]">
irb#1(main):045:0>
irb#1(main):017:0* all(:xpath, "//li[matches(#id, '^divPictureAndPrices_productListItem\d{0,2}$')]")
Selenium::WebDriver::Error::InvalidSelectorError: invalid selector: Unable to locate an element with the xpath expression //li[matches(#id, '^divPictureAndPrices_productListItemd{0,2}$')] because of the following error:
SyntaxError: Failed to execute 'evaluate' on 'Document': The string '//li[matches(#id, '^divPictureAndPrices_productListItemd{0,2}$')]' is not a valid XPath expression.
(Session info: chrome=48.0.2564.116)
(Driver info: chromedriver=2.20.353124 (035346203162d32c80f1dce587c8154a1efa0c3b),platform=Mac OS X 10.11.3 x86_64)
from /Library/Ruby/Gems/2.0.0/gems/selenium-webdriver-2.52.0/lib/selenium/webdriver/remote/response.rb:70:in `assert_ok'
from /Library/Ruby/Gems/2.0.0/gems/selenium-webdriver-2.52.0/lib/selenium/webdriver/remote/response.rb:34:in `initialize'
from /Library/Ruby/Gems/2.0.0/gems/selenium-webdriver-2.52.0/lib/selenium/webdriver/remote/http/common.rb:78:in `new'
from /Library/Ruby/Gems/2.0.0/gems/selenium-webdriver-2.52.0/lib/selenium/webdriver/remote/http/common.rb:78:in `create_response'
from /Library/Ruby/Gems/2.0.0/gems/selenium-webdriver-2.52.0/lib/selenium/webdriver/remote/http/default.rb:90:in `request'
from /Library/Ruby/Gems/2.0.0/gems/selenium-webdriver-2.52.0/lib/selenium/webdriver/remote/http/common.rb:59:in `call'
from /Library/Ruby/Gems/2.0.0/gems/selenium-webdriver-2.52.0/lib/selenium/webdriver/remote/bridge.rb:645:in `raw_execute'
from /Library/Ruby/Gems/2.0.0/gems/selenium-webdriver-2.52.0/lib/selenium/webdriver/remote/bridge.rb:623:in `execute'
from /Library/Ruby/Gems/2.0.0/gems/selenium-webdriver-2.52.0/lib/selenium/webdriver/remote/bridge.rb:602:in `find_elements_by'
from /Library/Ruby/Gems/2.0.0/gems/selenium-webdriver-2.52.0/lib/selenium/webdriver/common/search_context.rb:84:in `find_elements'
from /Library/Ruby/Gems/2.0.0/gems/capybara-2.6.2/lib/capybara/selenium/driver.rb:69:in `find_xpath'
from /Library/Ruby/Gems/2.0.0/gems/capybara-2.6.2/lib/capybara/node/base.rb:107:in `find_xpath'
from /Library/Ruby/Gems/2.0.0/gems/capybara-2.6.2/lib/capybara/query.rb:110:in `block in resolve_for'
from /Library/Ruby/Gems/2.0.0/gems/capybara-2.6.2/lib/capybara/node/base.rb:80:in `synchronize'
from /Library/Ruby/Gems/2.0.0/gems/capybara-2.6.2/lib/capybara/query.rb:106:in `resolve_for'
from /Library/Ruby/Gems/2.0.0/gems/capybara-2.6.2/lib/capybara/node/finders.rb:182:in `block in all'
from /Library/Ruby/Gems/2.0.0/gems/capybara-2.6.2/lib/capybara/node/base.rb:84:in `synchronize'
from /Library/Ruby/Gems/2.0.0/gems/capybara-2.6.2/lib/capybara/node/finders.rb:181:in `all'
from /Library/Ruby/Gems/2.0.0/gems/capybara-2.6.2/lib/capybara/session.rb:686:in `block (2 levels) in <class:Session>'
from /Library/Ruby/Gems/2.0.0/gems/capybara-2.6.2/lib/capybara/dsl.rb:51:in `block (2 levels) in <module:DSL>'
from (irb#1):17irb#1(main):018:0>
this is also not working:
find(:xpath, "//li[matches(#id, '^divPictureAndPrices_productListItem\d{0,2}$')]")
please help me on solving problem?
matches is supported only in xpath2.0.
if your xpath processor is 1.0 compliant only, then you must use contains.
find(:xpath, "//li[contains(#id, 'divPictureAndPrices_productListItem')]")
I can't understand why bullect gem is complaining about n+1 queries when I actually included it in my query
Issue
N+1 Query detected
AddonTypeValue => [:addon_option_values]
Add to your finder: :includes => [:addon_option_values]
Query
addon_types = AddonType.includes(addon_type_values:
[addon_option_values: :addon_option_type]).
where(addon_type_values: {published: true, design_id: self.id}).
where{addon_type.addon_type_values.visible_for != not_for}
My view - jbuilder
json.addon_option_values addon_type_value.addon_option_values do |aov|
json.id aov.id
json.p_name aov.p_name
json.position aov.position
end
Request Output Log - N+1 Query method call stack
/app/views/api/v1/designs/show.json.jbuilder:45:in `block (2 levels) in _app_views_api_v__designs_show_json_jbuilder___3899644929766612648_11335760'
/app/views/api/v1/designs/show.json.jbuilder:39:in `block in _app_views_api_v__designs_show_json_jbuilder___3899644929766612648_11335760'
/app/views/api/v1/designs/show.json.jbuilder:35:in `_app_views_api_v__designs_show_json_jbuilder___3899644929766612648_11335760'
/app/views/api/v1/designs/show.json.jbuilder:45:in `block (2 levels) in _app_views_api_v__designs_show_json_jbuilder___3899644929766612648_11335760'
/app/views/api/v1/designs/show.json.jbuilder:39:in `block in _app_views_api_v__designs_show_json_jbuilder___3899644929766612648_11335760'
/app/views/api/v1/designs/show.json.jbuilder:35:in `_app_views_api_v__designs_show_json_jbuilder___3899644929766612648_11335760'
I am using the jenkins cookbook to set up a windows slave on AWS. Locally (vagrant on virtualbox), it converges correctly, but when provisioning a new machine on aws using chef-provisioning and the fog driver, I run into the following error:
================================================================================
Error executing action `create` on resource 'jenkins_windows_slave[build-slave]'
================================================================================
Mixlib::ShellOut::ShellCommandFailed
------------------------------------
Expected process to exit with [0], but received '1'
---- Begin output of "java" -jar "C:\chef\cache/jenkins-cli.jar" -s http://10.0.0.5:8080 groovy C:/Users/ADMINI~1/AppData/Local/Temp/groovy20150312-536-1d2hoy4 ----
STDOUT: Error occurred during initialization of VM
Unable to allocate 61440KB bitmaps for parallel garbage collection for the requested 1966080KB heap.
STDERR: Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
---- End output of "java" -jar "C:\chef\cache/jenkins-cli.jar" -s http://10.0.0.5:8080 groovyC:/Users/ADMINI~1/AppData/Local/Temp/groovy20150312-536-1d2hoy4 ----
Ran "java" -jar "C:\chef\cache/jenkins-cli.jar" -s http://10.0.0.5:8080 groovy C:/Users/ADMINI~1/AppData/Local/Temp/groovy20150312-536-1d2hoy4 returned 1
Resource Declaration:
---------------------
# In C:/chef/cache/cookbooks/xyz_jenkins/recipes/slave_windows.rb
53: jenkins_windows_slave node['jenkins']['node']['name'] do
54: remote_fs node['jenkins']['node']['remote_fs'] # jenkins workspace items stored here
55: group node['jenkins']['node']['group'] # Group with access to remote_fs
56: user node['jenkins']['node']['user'] # user the service runs under (and remote_fs owner)
57: password node['jenkins']['node']['password'] # for user running the service
58: labels node['jenkins']['node']['labels'] # labels on Jenkins master
59: action :create
60: end
Compiled Resource:
------------------
# Declared in C:/chef/cache/cookbooks/xyz_jenkins/recipes/slave_windows.rb:53:in `from_file'
jenkins_windows_slave("build-slave") do
action [:create]
retries 0
retry_delay 2
default_guard_interpreter :default
declared_type :jenkins_windows_slave
cookbook_name "xyz_jenkins"
recipe_name "slave_windows"
remote_fs "C:\\jenkins"
group "Everyone"
user "jenkins"
password "apasswordhere"
labels ["builder", "windows"]
slave_name "build-slave"
end
chef-provisioning's stack trace:
U:/.chefdk/gem/ruby/2.0.0/gems/chef-provisioning-0.19/lib/chef/provisioning/transport/winrm.rb:144:in `error!'
U:/.chefdk/gem/ruby/2.0.0/gems/chef-provisioning-0.19/lib/chef/provisioning/machine/basic_machine.rb:31:in `block in execute'
C:/opscode/chefdk/embedded/apps/chef/lib/chef/mixin/why_run.rb:52:in `call'
C:/opscode/chefdk/embedded/apps/chef/lib/chef/mixin/why_run.rb:52:in `add_action'
C:/opscode/chefdk/embedded/apps/chef/lib/chef/provider.rb:180:in `converge_by'
U:/.chefdk/gem/ruby/2.0.0/gems/chef-provisioning-0.19/lib/chef/provisioning/chef_provider_action_handler.rb:54:in `perform_action'
U:/.chefdk/gem/ruby/2.0.0/gems/chef-provisioning-0.19/lib/chef/provisioning/machine/basic_machine.rb:29:in `execute'
U:/.chefdk/gem/ruby/2.0.0/gems/chef-provisioning-0.19/lib/chef/provisioning/convergence_strategy/install_msi.rb:49:in`block (2 levels) in converge'
C:/opscode/chefdk/embedded/apps/chef/lib/chef/run_context.rb:268:in `open_stream'
U:/.chefdk/gem/ruby/2.0.0/gems/chef-provisioning-0.19/lib/chef/provisioning/chef_provider_action_handler.rb:59:in `open_stream'
U:/.chefdk/gem/ruby/2.0.0/gems/chef-provisioning-0.19/lib/chef/provisioning/convergence_strategy/install_msi.rb:46:in`block in converge'
C:/opscode/chefdk/embedded/apps/chef/lib/chef/run_context.rb:268:in `open_stream'
U:/.chefdk/gem/ruby/2.0.0/gems/chef-provisioning-0.19/lib/chef/provisioning/chef_provider_action_handler.rb:59:in `open_stream'
U:/.chefdk/gem/ruby/2.0.0/gems/chef-provisioning-0.19/lib/chef/provisioning/convergence_strategy/install_msi.rb:45:in`converge'
U:/.chefdk/gem/ruby/2.0.0/gems/chef-provisioning-0.19/lib/chef/provisioning/machine/basic_machine.rb:21:in `converge'
U:/.chefdk/gem/ruby/2.0.0/gems/chef-provisioning-0.19/lib/chef/provider/machine.rb:62:in `block in <class:Machine>'
C:/opscode/chefdk/embedded/apps/chef/lib/chef/provider/lwrp_base.rb:60:in `instance_eval'
C:/opscode/chefdk/embedded/apps/chef/lib/chef/provider/lwrp_base.rb:60:in `recipe_eval_with_update_check'
C:/opscode/chefdk/embedded/apps/chef/lib/chef/provider/lwrp_base.rb:45:in `block in action'
C:/opscode/chefdk/embedded/apps/chef/lib/chef/provider.rb:145:in `run_action'
C:/opscode/chefdk/embedded/apps/chef/lib/chef/resource.rb:582:in `run_action'
C:/opscode/chefdk/embedded/apps/chef/lib/chef/runner.rb:49:in `run_action'
C:/opscode/chefdk/embedded/apps/chef/lib/chef/runner.rb:81:in `block (2 levels) in converge'
C:/opscode/chefdk/embedded/apps/chef/lib/chef/runner.rb:81:in `each'
C:/opscode/chefdk/embedded/apps/chef/lib/chef/runner.rb:81:in `block in converge'
C:/opscode/chefdk/embedded/apps/chef/lib/chef/resource_collection/resource_list.rb:83:in `block in execute_each_resource'
C:/opscode/chefdk/embedded/apps/chef/lib/chef/resource_collection/stepable_iterator.rb:116:in `call'
C:/opscode/chefdk/embedded/apps/chef/lib/chef/resource_collection/stepable_iterator.rb:116:in `call_iterator_block'
C:/opscode/chefdk/embedded/apps/chef/lib/chef/resource_collection/stepable_iterator.rb:85:in `step'
C:/opscode/chefdk/embedded/apps/chef/lib/chef/resource_collection/stepable_iterator.rb:104:in `iterate'
C:/opscode/chefdk/embedded/apps/chef/lib/chef/resource_collection/stepable_iterator.rb:55:in `each_with_index'
C:/opscode/chefdk/embedded/apps/chef/lib/chef/resource_collection/resource_list.rb:81:in `execute_each_resource'
C:/opscode/chefdk/embedded/apps/chef/lib/chef/runner.rb:80:in `converge'
C:/opscode/chefdk/embedded/apps/chef/lib/chef/client.rb:315:in `converge'
C:/opscode/chefdk/embedded/apps/chef/lib/chef/client.rb:400:in `block in run'
C:/opscode/chefdk/embedded/apps/chef/lib/chef/client.rb:399:in `catch'
C:/opscode/chefdk/embedded/apps/chef/lib/chef/client.rb:399:in `run'
C:/opscode/chefdk/embedded/apps/chef/lib/chef/application.rb:243:in `run_with_graceful_exit_option'
C:/opscode/chefdk/embedded/apps/chef/lib/chef/application.rb:220:in `block in run_chef_client'
C:/opscode/chefdk/embedded/apps/chef/lib/chef/local_mode.rb:38:in `with_server_connectivity'
C:/opscode/chefdk/embedded/apps/chef/lib/chef/application.rb:201:in `run_chef_client'
C:/opscode/chefdk/embedded/apps/chef/lib/chef/application/client.rb:355:in `block in interval_run_chef_client'
C:/opscode/chefdk/embedded/apps/chef/lib/chef/application/client.rb:345:in `loop'
C:/opscode/chefdk/embedded/apps/chef/lib/chef/application/client.rb:345:in `interval_run_chef_client'
C:/opscode/chefdk/embedded/apps/chef/lib/chef/application/client.rb:335:in `run_application'
C:/opscode/chefdk/embedded/apps/chef/lib/chef/application.rb:58:in `run'
C:/opscode/chefdk/embedded/apps/chef/bin/chef-client:26:in `<top (required)>'
C:/opscode/chefdk/bin/chef-client:52:in `load'
C:/opscode/chefdk/bin/chef-client:52:in `<main>'
chef run stack trace
C:/opscode/chef/embedded/lib/ruby/gems/2.0.0/gems/mixlib-shellout-2.0.1-x86-mingw32/lib/mixlib/shellout.rb:278:in `invalid!'
C:/opscode/chef/embedded/lib/ruby/gems/2.0.0/gems/mixlib-shellout-2.0.1-x86-mingw32/lib/mixlib/shellout.rb:265:in `error!'
C:/chef/cache/cookbooks/jenkins/libraries/_executor.rb:82:in `execute!'
C:/chef/cache/cookbooks/jenkins/libraries/_executor.rb:127:in `groovy!'
C:/chef/cache/cookbooks/jenkins/libraries/slave.rb:315:in `current_slave'
C:/chef/cache/cookbooks/jenkins/libraries/slave.rb:129:in `load_current_resource'
C:/chef/cache/cookbooks/jenkins/libraries/slave_jnlp.rb:52:in `load_current_resource'
C:/chef/cache/cookbooks/jenkins/libraries/slave_windows.rb:62:in `load_current_resource'
C:/opscode/chef/embedded/apps/chef/lib/chef/provider.rb:128:in `run_action'
C:/opscode/chef/embedded/apps/chef/lib/chef/resource.rb:561:in `run_action'
C:/opscode/chef/embedded/apps/chef/lib/chef/runner.rb:49:in `run_action'
C:/opscode/chef/embedded/apps/chef/lib/chef/runner.rb:81:in `block (2 levels) in converge'
C:/opscode/chef/embedded/apps/chef/lib/chef/runner.rb:81:in `each'
C:/opscode/chef/embedded/apps/chef/lib/chef/runner.rb:81:in `block in converge'
C:/opscode/chef/embedded/apps/chef/lib/chef/resource_collection/resource_list.rb:83:in `block in execute_each_resource'
C:/opscode/chef/embedded/apps/chef/lib/chef/resource_collection/stepable_iterator.rb:116:in `call'
C:/opscode/chef/embedded/apps/chef/lib/chef/resource_collection/stepable_iterator.rb:116:in `call_iterator_block'
C:/opscode/chef/embedded/apps/chef/lib/chef/resource_collection/stepable_iterator.rb:85:in `step'
C:/opscode/chef/embedded/apps/chef/lib/chef/resource_collection/stepable_iterator.rb:104:in `iterate'
C:/opscode/chef/embedded/apps/chef/lib/chef/resource_collection/stepable_iterator.rb:55:in `each_with_index'
C:/opscode/chef/embedded/apps/chef/lib/chef/resource_collection/resource_list.rb:81:in `execute_each_resource'
C:/opscode/chef/embedded/apps/chef/lib/chef/runner.rb:80:in `converge'
C:/opscode/chef/embedded/apps/chef/lib/chef/client.rb:331:in `block in converge'
C:/opscode/chef/embedded/apps/chef/lib/chef/client.rb:326:in `catch'
C:/opscode/chef/embedded/apps/chef/lib/chef/client.rb:326:in `converge'
C:/opscode/chef/embedded/apps/chef/lib/chef/client.rb:345:in `converge_and_save'
C:/opscode/chef/embedded/apps/chef/lib/chef/client.rb:448:in `run'
C:/opscode/chef/embedded/apps/chef/lib/chef/application.rb:253:in `run_with_graceful_exit_option'
C:/opscode/chef/embedded/apps/chef/lib/chef/application.rb:230:in `block in run_chef_client'
C:/opscode/chef/embedded/apps/chef/lib/chef/local_mode.rb:38:in `with_server_connectivity'
C:/opscode/chef/embedded/apps/chef/lib/chef/application.rb:213:in `run_chef_client'
C:/opscode/chef/embedded/apps/chef/lib/chef/application/client.rb:392:in `block in interval_run_chef_client'
C:/opscode/chef/embedded/apps/chef/lib/chef/application/client.rb:382:in `loop'
C:/opscode/chef/embedded/apps/chef/lib/chef/application/client.rb:382:in `interval_run_chef_client'
C:/opscode/chef/embedded/apps/chef/lib/chef/application/client.rb:372:in `run_application'
C:/opscode/chef/embedded/apps/chef/lib/chef/application.rb:60:in `run'
C:/opscode/chef/embedded/apps/chef/bin/chef-client:26:in `<top (required)>'
C:/opscode/chef/bin/chef-client:64:in `load'
C:/opscode/chef/bin/chef-client:64:in `<main>'
I have tried different versions of the chef-client to resolve the issue, but that did not help. I'm not sure if the problem is with the jenkins recipe, chef-provisioning, or what.
Because the jenkins recipes work on a local vagrant machine running the same OS (win 2012 R2), I'm thinking this may be a problem with chef-provisioning-fog.
It turns out the problem is with WinRM. The current version of the chef-provisioning-fog driver hard-codes the AWS user data in order to set up WinRM on the machine. Part of this setup sets the per-shell memory limit to 300MB, and the java command executed by the jenkins recipe wants to reserve 2GB of heap; hence the fatal error.
The short-term fix is to up the per-shell WinRM limit from 300MB to 2GB:
set-item wsman:localhost\Shell\MaxMemoryPerShellMB 2048
With chef-provisioning, put this resource after getting the machine ready and before converging:
machine_execute 'set-item wsman:localhost\Shell\MaxMemoryPerShellMB 2048' do
machine "jenkins-win-slave-#{i}"
end
Long term, hopefully the issue is resolved and user data can be customized to set up winrm however the user sees fit.
This is my first time using stack overflow for a personal question and I have searched for an answer to my question, with no success, so please be patient with me if I have overlooked anything, and thank you in advance for your help.
I'm currently making an application using ruby on rails 4 version 4.1.1 (using RVM) and it seems that every time I enter any rake or rails command (such as rails server or rails console) in the command line, there is a 50/50 chance that it will work as planned, the rest of the time I get the following error message:
/Users/drobro/.rvm/gems/ruby-2.1.2#global/gems/bundler-1.6.2/lib/bundler/runtime.rb:222:in `split': invalid byte sequence in UTF-8 (ArgumentError)
from /Users/drobro/.rvm/gems/ruby-2.1.2#global/gems/bundler-1.6.2/lib/bundler/runtime.rb:224:in `setup_environment'
from /Users/drobro/.rvm/gems/ruby-2.1.2#global/gems/bundler-1.6.2/lib/bundler/runtime.rb:17:in `setup'
from /Users/drobro/.rvm/gems/ruby-2.1.2#global/gems/bundler-1.6.2/lib/bundler.rb:120:in `setup'
from /Users/drobro/.rvm/gems/ruby-2.1.2#global/gems/rubygems-bundler-1.4.4/lib/rubygems-bundler/noexec.rb:94:in `setup'
from /Users/drobro/.rvm/gems/ruby-2.1.2#global/gems/rubygems-bundler-1.4.4/lib/rubygems-bundler/noexec.rb:124:in `check'
from /Users/drobro/.rvm/gems/ruby-2.1.2#global/gems/rubygems-bundler-1.4.4/lib/rubygems-bundler/noexec.rb:131:in `<top (required)>'
from /Users/drobro/.rvm/rubies/ruby-2.1.2/lib/ruby/2.1.0/rubygems/core_ext/kernel_require.rb:135:in `require'
from /Users/drobro/.rvm/rubies/ruby-2.1.2/lib/ruby/2.1.0/rubygems/core_ext/kernel_require.rb:135:in `rescue in require'
from /Users/drobro/.rvm/rubies/ruby-2.1.2/lib/ruby/2.1.0/rubygems/core_ext/kernel_require.rb:144:in `require'
from /Users/drobro/.rvm/gems/ruby-2.1.2#global/gems/rubygems-bundler-1.4.4/lib/rubygems_executable_plugin.rb:4:in `block in <top (required)>'
from /Users/drobro/.rvm/gems/ruby-2.1.2#global/gems/executable-hooks-1.3.2/lib/executable-hooks/hooks.rb:50:in `call'
from /Users/drobro/.rvm/gems/ruby-2.1.2#global/gems/executable-hooks-1.3.2/lib/executable-hooks/hooks.rb:50:in `block in run'
from /Users/drobro/.rvm/gems/ruby-2.1.2#global/gems/executable-hooks-1.3.2/lib/executable-hooks/hooks.rb:49:in `each'
from /Users/drobro/.rvm/gems/ruby-2.1.2#global/gems/executable-hooks-1.3.2/lib/executable-hooks/hooks.rb:49:in `run'
from /Users/drobro/.rvm/gems/ruby-2.1.2/bin/ruby_executable_hooks:10:in `<main>'
Now, I went to check the apparently faulty code in the runtime.rb and it looks like this:
def setup_environment
begin
ENV["BUNDLE_BIN_PATH"] = Bundler.rubygems.bin_path("bundler", "bundle", VERSION)
rescue Gem::GemNotFoundException
ENV["BUNDLE_BIN_PATH"] = File.expand_path("../../../bin/bundle", __FILE__)
end
# Set PATH
paths = (ENV["PATH"] || "").split(File::PATH_SEPARATOR)
paths.unshift "#{Bundler.bundle_path}/bin"
ENV["PATH"] = paths.uniq.join(File::PATH_SEPARATOR)
# Set BUNDLE_GEMFILE
ENV["BUNDLE_GEMFILE"] = default_gemfile.to_s
# Set RUBYOPT
rubyopt = [ENV["RUBYOPT"]].compact
if rubyopt.empty? || rubyopt.first !~ /-rbundler\/setup/
rubyopt.unshift %|-rbundler/setup|
ENV["RUBYOPT"] = rubyopt.join(' ')
end
# Set RUBYLIB
rubylib = (ENV["RUBYLIB"] || "").split(File::PATH_SEPARATOR)
rubylib.unshift File.expand_path('../..', __FILE__)
ENV["RUBYLIB"] = rubylib.uniq.join(File::PATH_SEPARATOR)
end
at line 222, which is the line right beneath the # Set PATH comment, i.e. paths = (ENV["PATH"] || "").split(File::PATH_SEPARATOR). From what I understand, this is telling me that the argument to the split method, File::PATH_SEPARATOR, is invalid in UTF-8 encoding. I decided to throw in some puts statements around that code to check what was going on. So, right under # Set PATH, I typed:
puts "File::PATH_SEPARATOR is this: #{File::PATH_SEPARATOR}"
puts "This is the encoding: #{File::PATH_SEPARATOR.encoding}"
File::PATH_SEPARATOR.each_byte do |c|
puts "This is the ASCII value: #{c}"
end
ON THE TIMES WHEN A RAILS COMMAND DOES NOT WORK, the output to the terminal is:
File::PATH_SEPARATOR is this: :
This is the encoding: ASCII-8BIT
This is the ASCII value: 58
/Users/drobro/.rvm/gems/ruby-2.1.2#global/gems/bundler-1.6.2/lib/bundler/runtime.rb:227:in `split': invalid byte sequence in UTF-8 (ArgumentError)
from /Users/drobro/.rvm/gems/ruby-2.1.2#global/gems/bundler-1.6.2/lib/bundler/runtime.rb:224:in `setup_environment'
from /Users/drobro/.rvm/gems/ruby-2.1.2#global/gems/bundler-1.6.2/lib/bundler/runtime.rb:15:in `setup'
from /Users/drobro/.rvm/gems/ruby-2.1.2#global/gems/bundler-1.6.2/lib/bundler.rb:120:in `setup'
from /Users/drobro/.rvm/gems/ruby-2.1.2#global/gems/rubygems-bundler-1.4.4/lib/rubygems-bundler/noexec.rb:94:in `setup'
from /Users/drobro/.rvm/gems/ruby-2.1.2#global/gems/rubygems-bundler-1.4.4/lib/rubygems-bundler/noexec.rb:124:in `check'
from /Users/drobro/.rvm/gems/ruby-2.1.2#global/gems/rubygems-bundler-1.4.4/lib/rubygems-bundler/noexec.rb:131:in `<top (required)>'
from /Users/drobro/.rvm/rubies/ruby-2.1.2/lib/ruby/2.1.0/rubygems/core_ext/kernel_require.rb:135:in `require'
from /Users/drobro/.rvm/rubies/ruby-2.1.2/lib/ruby/2.1.0/rubygems/core_ext/kernel_require.rb:135:in `rescue in require'
from /Users/drobro/.rvm/rubies/ruby-2.1.2/lib/ruby/2.1.0/rubygems/core_ext/kernel_require.rb:144:in `require'
from /Users/drobro/.rvm/gems/ruby-2.1.2#global/gems/rubygems-bundler-1.4.4/lib/rubygems_executable_plugin.rb:4:in `block in <top (required)>'
from /Users/drobro/.rvm/gems/ruby-2.1.2#global/gems/executable-hooks-1.3.2/lib/executable-hooks/hooks.rb:50:in `call'
from /Users/drobro/.rvm/gems/ruby-2.1.2#global/gems/executable-hooks-1.3.2/lib/executable-hooks/hooks.rb:50:in `block in run'
from /Users/drobro/.rvm/gems/ruby-2.1.2#global/gems/executable-hooks-1.3.2/lib/executable-hooks/hooks.rb:49:in `each'
from /Users/drobro/.rvm/gems/ruby-2.1.2#global/gems/executable-hooks-1.3.2/lib/executable-hooks/hooks.rb:49:in `run'
from /Users/drobro/.rvm/gems/ruby-2.1.2/bin/ruby_executable_hooks:10:in `<main>'
AND ON THE TIMES WHEN A RAILS COMMAND DOES WORK, the output to the terminal is (this example is for the rails server command):
File::PATH_SEPARATOR is this: :
This is the encoding: ASCII-8BIT
This is the ASCII value: 58
File::PATH_SEPARATOR is this: :
This is the encoding: ASCII-8BIT
This is the ASCII value: 58
=> Booting WEBrick
=> Rails 4.1.0 application starting in development on http://0.0.0.0:3000
=> Run `rails server -h` for more startup options
=> Notice: server is listening on all interfaces (0.0.0.0). Consider using 127.0.0.1 (--binding option)
=> Ctrl-C to shutdown server
[2014-07-08 17:36:40] INFO WEBrick 1.3.1
[2014-07-08 17:36:40] INFO ruby 2.1.2 (2014-05-08) [x86_64-darwin13.0]
[2014-07-08 17:36:40] INFO WEBrick::HTTPServer#start: pid=6447 port=3000
This is what worries me: the information returned is IDENTICAL in both cases. What's worse is that the encoding is ASCII-8BIT, which is more restrictive than UTF-8, and anyways the invalid character is supposedly just a colon... which should never cause any problems in either of those encodings right?? So I have 2 questions:
1) Why in the world am I getting this invalid utf-8 error?
2) Why does it only happen half the time despite the input being identical??
Thank you for helping, I'm at a loss here.
I managed to fix the problem by changing the line:
paths = (ENV["PATH"] || "").split(File::PATH_SEPARATOR)
to:
paths = (ENV["PATH"] || "").encode('UTF-8', :invalid => :replace).split(File::PATH_SEPARATOR)
My understanding is that this will replace an invalid UTF-8 byte sequence with (an equivalent??) one that is valid. However, this does not explain why the problem was happening just half the time, and that is what was really getting to me.
So, if anyone reads this and has any clue as to what was happening, please feel free to comment and let me know, it would be very much appreciated.