I’m new to Circle Ci. I was trying to test in on a sample ruby on rails blog application but always seems to find the error.
Alright, thanks for letting us know! 
I’m getting the same error. Ruby 2.2 and usually a rebuild gets rid of it, but it’s quite annoying.
#!/bin/bash --login
export RAILS_ENV="test"
export RACK_ENV="test"
bundle exec rspec --colour --require spec_helper --format RspecJunitFormatter --out $CIRCLE_TEST_REPORTS/rspec/rspec.xml --format progress $(circleci tests glob spec/**/*.rb | circleci tests split)
bundler: failed to load command: rspec (/home/circleci/MyApp/vendor/bundle/ruby/2.2.0/bin/rspec)
NameError: uninitialized constant MyApp::SqlProxyAwsExportSupport
/home/circleci/MyApp/lib/my_app/kewill_sql_proxy_client.rb:7:in `<class:KewillSqlProxyClient>'
/home/circleci/MyApp/lib/my_app/kewill_sql_proxy_client.rb:6:in `<module:MyApp>'
/home/circleci/MyApp/lib/my_app/kewill_sql_proxy_client.rb:6:in `<top (required)>'
/home/circleci/MyApp/lib/my_app/custom_handler/intacct/alliance_day_end_handler.rb:6:in `<top (required)>'
/home/circleci/MyApp/lib/my_app/custom_handler/intacct/alliance_day_end_ar_ap_parser.rb:2:in `<top (required)>'
/home/circleci/MyApp/lib/my_app/integration_client.rb:34:in `<top (required)>'
/home/circleci/MyApp/lib/my_app/sql_proxy_aws_export_support.rb:3:in `<top (required)>'
/home/circleci/MyApp/spec/spec_helper.rb:16:in `block in <top (required)>'
/home/circleci/MyApp/spec/spec_helper.rb:16:in `each'
/home/circleci/MyApp/spec/spec_helper.rb:16:in `<top (required)>'
/home/circleci/MyApp/vendor/bundle/ruby/2.2.0/gems/rspec-core-3.5.4/lib/rspec/core/configuration.rb:1394:in `require'
/home/circleci/MyApp/vendor/bundle/ruby/2.2.0/gems/rspec-core-3.5.4/lib/rspec/core/configuration.rb:1394:in `block in requires='
/home/circleci/MyApp/vendor/bundle/ruby/2.2.0/gems/rspec-core-3.5.4/lib/rspec/core/configuration.rb:1394:in `each'
/home/circleci/MyApp/vendor/bundle/ruby/2.2.0/gems/rspec-core-3.5.4/lib/rspec/core/configuration.rb:1394:in `requires='
/home/circleci/MyApp/vendor/bundle/ruby/2.2.0/gems/rspec-core-3.5.4/lib/rspec/core/configuration_options.rb:112:in `block in process_options_into'
/home/circleci/MyApp/vendor/bundle/ruby/2.2.0/gems/rspec-core-3.5.4/lib/rspec/core/configuration_options.rb:111:in `each'
/home/circleci/MyApp/vendor/bundle/ruby/2.2.0/gems/rspec-core-3.5.4/lib/rspec/core/configuration_options.rb:111:in `process_options_into'
/home/circleci/MyApp/vendor/bundle/ruby/2.2.0/gems/rspec-core-3.5.4/lib/rspec/core/configuration_options.rb:21:in `configure'
/home/circleci/MyApp/vendor/bundle/ruby/2.2.0/gems/rspec-core-3.5.4/lib/rspec/core/runner.rb:99:in `setup'
/home/circleci/MyApp/vendor/bundle/ruby/2.2.0/gems/rspec-core-3.5.4/lib/rspec/core/runner.rb:86:in `run'
/home/circleci/MyApp/vendor/bundle/ruby/2.2.0/gems/rspec-core-3.5.4/lib/rspec/core/runner.rb:71:in `run'
/home/circleci/MyApp/vendor/bundle/ruby/2.2.0/gems/rspec-core-3.5.4/lib/rspec/core/runner.rb:45:in `invoke'
/home/circleci/MyApp/vendor/bundle/ruby/2.2.0/gems/rspec-core-3.5.4/exe/rspec:4:in `<top (required)>'
/home/circleci/MyApp/vendor/bundle/ruby/2.2.0/bin/rspec:23:in `load'
/home/circleci/MyApp/vendor/bundle/ruby/2.2.0/bin/rspec:23:in `<top (required)>'
Exited with code 1Do you mean it’s intermittent?
OK, that’s odd: each new commit fails the build, and each rebuild of the same fixes it 
Would you put your config.yml here, in a formatted block, so readers can take a look? It feels like a problem to do with caching, I wonder.
I went ahead and removed the caching parts in this and pushed just to see. I’ll post back if that fixes the issue.
# This configuration was automatically generated from a CircleCI 1.0 config and manually edited to meet
# our needs for MyApp. It should include any build commands CircleCI inferred from your project structure.
# The idiom for configuration has changed substantially in 2.0 to allow arbitrary jobs rather
# than the prescribed lifecycle of 1.0.
version: 2
jobs:
build:
working_directory: ~/MyApp
parallelism: 2
shell: /bin/bash --login
# CircleCI 2.0 does not support environment variables that refer to each other the same way as 1.0 did.
# If any of these refer to each other, rewrite them so that they don't or see https://circleci.com/docs/2.0/env-vars/#interpolating-environment-variables-to-set-other-environment-variables .
environment:
CIRCLE_ARTIFACTS: /tmp/circleci-artifacts
CIRCLE_TEST_REPORTS: /tmp/circleci-test-results
# In CircleCI 1.0 we used a pre-configured image with a large number of languages and other packages.
# In CircleCI 2.0 you can now specify your own image, or use one of our pre-configured images.
# The following configuration line tells CircleCI to use the specified docker image as the runtime environment for you job.
# We have selected a pre-built image that mirrors the build environment we use on
# the 1.0 platform, but we recommend you choose an image more tailored to the needs
# of each job. For more information on choosing an image (or alternatively using a
# VM instead of a container) see https://circleci.com/docs/2.0/executor-types/
# To see the list of pre-built images that CircleCI provides for most common languages see
# https://circleci.com/docs/2.0/circleci-images/
docker:
- image: circleci/ruby:2.2.9-browsers
environment:
RAILS_ENV: test
DB_HOST: localhost
REDIS_HOST: 127.0.0.1
command: /sbin/init
# We don't use utf8mb4 because real utf doesn't fit into the index
# https://stackoverflow.com/questions/42043205/how-to-fix-mysql-index-column-size-too-large-laravel-migrate
- image: circleci/mysql:5.6.37-ram
command: mysqld --character-set-server=utf8 --collation-server=utf8_unicode_ci --innodb-large-prefix=true --innodb-file-format=Barracuda --sort-buffer-size=67108864
- image: redis
steps:
# Machine Setup
# If you break your build into multiple jobs with workflows, you will probably want to do the parts of this that are relevant in each
# The following `checkout` command checks out your code to your working directory. In 1.0 we did this implicitly. In 2.0 you can choose where in the course of a job your code should be checked out.
- checkout
# Prepare for artifact and test results collection equivalent to how it was done on 1.0.
# In many cases you can simplify this from what is generated here.
# 'See docs on artifact collection here https://circleci.com/docs/2.0/artifacts/'
- run: mkdir -p $CIRCLE_ARTIFACTS $CIRCLE_TEST_REPORTS
# This is based on your 1.0 configuration file or project settings
- run: mkdir ./tmp
- run: mkdir ./spec/support/tmp
# The following line was run implicitly in your 1.0 builds based on what CircleCI inferred about the structure of your project. In 2.0 you need to be explicit about which commands should be run. In some cases you can discard inferred commands if they are not relevant to your project.
- run: echo -e "export RAILS_ENV=test\nexport RACK_ENV=test" >> $BASH_ENV
- run: 'bundle check --path=vendor/bundle || bundle install --path=vendor/bundle --jobs=4 --retry=3'
# The following line was run implicitly in your 1.0 builds based on what CircleCI inferred about the structure of your project. In 2.0 you need to be explicit about which commands should be run. In some cases you can discard inferred commands if they are not relevant to your project.
# Save dependency cache
- save_cache:
key: v1-dep-{{ .Branch }}-{{ epoch }}
paths:
- vendor/bundle
- ~/.bundle
- ~/.cache/bower
- run: |-
mkdir -p config && echo 'test:
adapter: mysql2
database: circle_test
username: root
host: 127.0.0.1
' > config/database.yml
- run: |-
export RAILS_ENV="test"
export RACK_ENV="test"
bundle exec rake db:create db:migrate --trace
# This is temporary solution to the problems that occur with phantomjs 2.x
# https://discuss.circleci.com/t/rake-spec-passes-all-tests-then-fails-from-non-zero-exit-code/20428
- run: |-
cd /usr/local/share
sudo wget https://repo1.maven.org/maven2/com/github/klieber/phantomjs/1.9.0/phantomjs-1.9.0-linux-x86_64.tar.bz2
sudo tar xjf phantomjs-1.9.0-linux-x86_64.tar.bz2
sudo ln -s /usr/local/share/phantomjs-1.9.0-linux-x86_64/bin/phantomjs /usr/local/share/phantomjs
sudo rm /usr/local/bin/phantomjs
sudo ln -s /usr/local/share/phantomjs-1.9.0-linux-x86_64/bin/phantomjs /usr/local/bin/phantomjs
sudo ln -s /usr/local/share/phantomjs-1.9.0-linux-x86_64/bin/phantomjs /usr/bin/phantomjs
- run: mkdir -p $CIRCLE_TEST_REPORTS/rspec
# TEST_FILES is broken out into it's own variable because of random bash parsing issues which case "bundler: failed to load command: rspec"
- run: |-
export RAILS_ENV="test"
export RACK_ENV="test"
bundle exec rspec --colour --require spec_helper --format RspecJunitFormatter --out $CIRCLE_TEST_REPORTS/rspec/rspec.xml --format progress $(circleci tests glob spec/**/*.rb | circleci tests split)
# This is based on your 1.0 configuration file or project settings
- run:
name: bundle exec rake spec:javascript
command: |-
export RAILS_ENV="test"
if [ "$CIRCLE_NODE_INDEX" == "0" ]; then bundle exec rake spec:javascript; fi
# Teardown
# If you break your build into multiple jobs with workflows, you will probably want to do the parts of this that are relevant in each
# Save test results
- store_test_results:
path: /tmp/circleci-test-results
# Save artifacts
- store_artifacts:
path: /tmp/circleci-artifacts
- store_artifacts:
path: /tmp/circleci-test-results
1 Like
Um, yeah - you have a save_cache but no restore_cache.
Good catch, but doesn’t seem to solve the issue. Removing both save/restore and having both the save/restore and I still have the issue. Oddly however, I running with both save/restore cache the tests all ran fine and than it failed to load command after the fact!
Ooh, righto. Well, stick with the cache commands removed to start with - the less config to debug, the better!
So looking at my previous builds that were succeeding and comparing the timings with the ones that are now failing, it looks like everything runs on both containers, but if one fails than everything counts as a failure. Parallelism is set to two with the automatically generated config, but I don’t think this is actually aiding me because of how serially the original config was with 1.0 circleci
This is what happens recently:
This is what was happening yesterday
And there is always the possibility that they both fail.
I believe this to be an intermittent issue, but a more likely one with more containers. Based on previous posts it seems to have been an issue with the circleci docker image that was being used for ruby. So perhaps there is a incremental deployment cycle in case something like this breaks sometimes and hopefully someone catches it?
Does the problem go away if you reduce your parallelism to 1?
I’ve definitely removed the parallelism since I don’t have workflows or anything setup for parallel testing. I think that’s definitely reduced the amount of occurrences, but I’m willing to bet this will happen again.
1 Like
Hmm, OK. I wish I could help further, but I don’t know Ruby. I wonder if searching for the error “bundler: failed to load command: rspec” would be worthwhile, there is probably something on Stack Overflow.
I work with Fir3Chi3f, and the errors are actually due to some missing require statements and some circular dependencies in our ruby code.
What’s surprising is that the load order isn’t consistent between builds, though it appears that ruby’s Dir#[] method doesn’t ensure any sort of order in the filenames returned and by utilizing an alternate loading scheme (probably based on filename) we can enforce deterministic code load ordering.
2 Likes
Based on the feedback from @jhulford, parallelism is turned up to x6 and libraries are imported with sort. IE -
Dir[Rails.root.join("lib/**/*.rb")].sort.each {|f| require f}
So far so good on the builds 
1 Like