Bundler: command not found: rspec


#1

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.


#2

Alright, thanks for letting us know! :smile_cat:


#3

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 1

#4

Do you mean it’s intermittent?


#5

No, so far it fails with every new push. In this example I committed some comment changes.


#6

OK, that’s odd: each new commit fails the build, and each rebuild of the same fixes it :face_with_raised_eyebrow:

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.


#7

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

#8

Um, yeah - you have a save_cache but no restore_cache.


#9

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!


#10

Ooh, righto. Well, stick with the cache commands removed to start with - the less config to debug, the better!


#11

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?


#12

Does the problem go away if you reduce your parallelism to 1?


#13

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.


#14

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.


#15

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.


#16

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 :slight_smile:


#17