Different result depending the container number

I’m testing CircleCI and so far it looks good. But I’m facing a weird problem with parallelisation.

I’m running a build with 2 containers. And using a bash case statement to select which commands (rspec) to run in each container.

The specs executed in container 0 always work. The specs executed in container 1 always fail. If I move the commands from 1 to 0, they work.

Any idea why this might happen? The steps to get there are the same for both containers, I can’t think of a reason why some fail and some doesn’t. Maybe something on the db setup between containers is different?

I’m using a database configuration taken from the first run I did. You can see it below.

circle.yml

machine:
  ruby:
    version: 2.2.6
  node:
    version: 4.2.6
  environment:
    RAILS_ENV: test
  services:
    - redis
database:
  override:
    - cp config/database.circle.yml config/database.yml
    - bundle exec rake db:create db:schema:load
test:
  pre:
    - npm run build
  override:
    - bundle exec rubocop -c .rubocop_strict.yml
    - ? |
        case $CIRCLE_NODE_INDEX in
          0)
            COUNTRY=Germany bundle exec rspec ./spec/features/single_country/de/
            COUNTRY=Australia bundle exec rspec ./spec/features/single_country/au/
            ;;
          1)
            COUNTRY=France bundle exec rspec ./spec/features/single_country/fr/
            COUNTRY=UK bundle exec rspec ./spec/features/single_country/uk/
            ;;
        esac
      :
        parallel: true

database.circle.yml

test:
  adapter: postgresql
  encoding: unicode
  database: circle_ruby_test
  username: ubuntu
  pool: 16
  host: localhost
  port: 5432

I just discovered why.
The npm run build is only being executed in container 0.

The solution is putting the parallel: true to the npm build

test:
  pre:
    - npm run build:
        parallel: true
1 Like

Your solution helped in another issue I was encountering due to parallelism.

The problem I think is the circlelci UI that confuses the user, as the command looks like to have been executed on all containers but actually ran on only the first.