I am having issues running tests with cucumber in CircleCI because the CSS files are not loading properly.
I ran the project in the test environment RAILS_ENV=test rails s and it is not loading the CSS (even though I can see the CSS generated by RAILS_ENV=test rake assets:precompile). It will only load correctly if I run rake assets:precompile before. But how can I do this for circleCI?
Likewise, locally I can run bundle exec cucumber without any failing tests (if I run rake assets:precompile before), but if I then user CircleCI to run the same tests I get the same failing tests as if I delete the public/assets folder and run bundle exec cucumber locally.
In my environment/test.rb I have added the files to config.assets.precompile
This is my applicatin.scss:
/*
*= require_self
*= require_tree ./shared
*= require_tree ./tenants
*= require_tree ./pages
*/
My Gemfile:
ruby '2.5.5'
source 'https://rubygems.org'
gem 'rails', '5.2'
gem 'bootstrap-sass'
gem 'coffee-rails'
gem 'haml-rails', "~> 1.0"
gem 'jquery-rails'
gem 'd3_rails'
gem 'sass-rails'
gem 'sass', '3.7.1'
gem 'select2-rails'
gem 'uglifier'
gem 'font-awesome-rails'
gem 'date'
gem 'fileutils'
gem 'browser'
gem 'bugsnag'
gem 'simple_form'
gem 'rack-mini-profiler'
gem 'acts-as-taggable-on', '~> 6.0'
gem 'acts_as_list', '0.9.5'
gem 'ckeditor'
gem 'gon', '~> 6.2.1'
gem 'devise'
gem 'handlebars_assets'
gem 'iconv', "~> 1.0.2"
gem 'non-stupid-digest-assets'
gem 'paperclip'
gem 'aws-sdk', '~> 3'
gem 'unicorn', '~> 5.4.1'
gem 'delayed_job_active_record'
gem 'mixpanel-ruby'
gem 'newrelic_rpm'
gem 'rails_12factor', group: :production
gem 'will_paginate'
gem 'doc_raptor', '~> 0.3.2'
gem 'validates_lengths_from_database'
gem 'active_model_serializers', '~> 0.8.3'
gem 'virtus'
gem 'curb'
gem 'rb-readline'
group :development, :test do
gem 'byebug'
gem 'rspec-rails'
gem 'rb-fsevent', '~> 0.9.1'
gem 'guard-rspec', '4.7.3'
gem 'guard-spork', '2.1.0'
gem 'spork', '0.9.2'
gem 'jasmine-rails'
gem 'teaspoon-jasmine'
end
group :development do
gem 'better_errors'
gem 'binding_of_caller'
gem 'letter_opener'
gem 'dotenv-rails'
gem 'daemons'
gem 'web-console', '~> 2.0'
gem 'pry-rails'
end
group :test do
gem 'capybara'
gem 'cucumber-rails', :require => false
gem 'database_cleaner'
gem 'factory_girl_rails', '4.1.0'
gem 'launchy'
gem 'poltergeist'
gem 'selenium-webdriver'
gem 'webdrivers', '~> 4.0'
gem 'phantomjs', :require => 'phantomjs/poltergeist'
gem 'timecop'
gem 'webmock'
gem 'simplecov', '~> 0.16.0'
gem 'rails-controller-testing'
gem 'execjs'
gem 'therubyracer'
end
group :production do
gem 'pg', '~> 0.19.0'
gem 'heroku-deflater'
end
CircleCI config file:
version: 2
jobs:
build:
working_directory: ~/xxxx/xxxxxx
parallelism: 1
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.5.5-browsers-legacy
environment:
PGHOST: 127.0.0.1
PGUSER: postgres
- image: circleci/postgres:9.6-alpine
environment:
POSTGRES_USER: postgres
POSTGRES_DB: xxxx-test
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
# Dependencies
# This would typically go in either a build or a build-and-test job when using workflows
# Restore the dependency cache
- restore_cache:
keys:
# This branch if available
- v1-dep-{{ .Branch }}-
# Default branch if not
- v1-dep-master-
# Any branch if there are none on the default branch - this should be unnecessary if you have your default branch configured correctly
- v1-dep-
# 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: sed -i.bak "/gem ['\"]growl_notify\|autotest-fsevent\|rb-appscript\|rb-fsevent['\"].*, *$/ N; s/\n *//g; /gem ['\"]growl_notify\|autotest-fsevent\|rb-appscript\|rb-fsevent['\"]/ d" Gemfile
- run: 'bundle check --path=vendor/bundle || bundle install --path=vendor/bundle --jobs=4 --retry=3 '
# Save dependency cache
- save_cache:
key: v1-dep-{{ .Branch }}-{{ epoch }}
paths:
# This is a broad list of cache paths to include many possible development environments
# You can probably delete some of these entries
- vendor/bundle
- ~/.bundle
# SETUP DB:
- run:
name: Database Setup
command: |
bundle exec rake db:create db:schema:load --trace
bundle exec rake db:migrate
environment:
DATABASE_URL: "postgres://postgres@localhost:5432/xxxx"
# Test
# This would typically be a build job when using workflows, possibly combined with build
# 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:
command: bundle exec rspec --color --format progress spec
environment:
RAILS_ENV: test
RACK_ENV: test
- run:
command: |
mkdir -p $CIRCLE_TEST_REPORTS/cucumber
bundle exec cucumber --format json --out $CIRCLE_TEST_REPORTS/cucumber/cucumber.cucumber
environment:
RAILS_ENV: test
RACK_ENV: test
# # This is based on your 1.0 configuration file or project settings
# - run: bundle exec rake teaspoon
# Deployment
# Your existing circle.yml file contains deployment steps.
# The config translation tool does not support translating deployment steps
# since deployment in CircleCI 2.0 are better handled through workflows.
# See the documentation for more information https://circleci.com/docs/2.0/workflows/
deploy:
machine:
enabled: true
working_directory: ~/xxx/xxxxx
environment:
HEROKU_APP: "XXXXXXX"
steps:
- checkout
- run:
name: Deploy Master to Heroku
command: |
git push https://heroku:$HEROKU_API_KEY@git.heroku.com/$HEROKU_APP.git master
workflows:
version: 2
build-and-deploy:
jobs:
- build
- deploy:
requires:
- build
filters:
branches:
only: master
