GitLab CI中Rspec+PhantomJS/Poltergeist集成测试运行失败求助

Let’s break down why your local tests work but GitLab CI can’t find application.css/application.js—this is almost always related to how Rails serves static assets in the test environment and how Capybara/Poltergeist interacts with them. Here are the key fixes to implement:

1. Enable Static File Serving in Test Environment #

By default, Rails disables static file serving in the test environment (since local development uses the asset pipeline server). But in CI, you’ve precompiled assets to public/assets, so the Rails server needs to serve these files directly.

Update your config/environments/test.rb:

# For Rails 4.x
config.serve_static_files = true

# For Rails 5+
config.public_file_server.enabled = true

# Disable runtime asset compilation (we already precompiled in CI)
config.assets.compile = false

2. Configure Capybara to Point to the Correct Asset Host #

Poltergeist (PhantomJS) needs to know where to fetch assets from. Add these lines to your Capybara config to ensure it uses the Rails server’s address for asset requests:

require 'capybara/rspec'
require 'capybara/poltergeist'
require 'capybara/rails'

Capybara.register_driver :poltergeist do |app|
  options = { 
    js_errors: true, 
    cookies: true, 
    inspector: true, 
    window_size: [2500, 2500],
    # Fix PhantomJS path/security quirks
    phantomjs_options: ['--web-security=no', '--ignore-ssl-errors=yes']
  }
  Capybara::Poltergeist::Driver.new(app, options)
end

Capybara.default_driver = :poltergeist
Capybara.javascript_driver = :poltergeist
Capybara.default_selector = :css

# Critical: Tell Capybara to use the test server for assets
Capybara.asset_host = "http://#{Capybara.server_host}:#{Capybara.server_port}"
# Use a server that reliably serves static files (Puma or Webrick)
Capybara.server = :puma

3. Verify Asset Precompilation in CI #

Add a check to your CI script to confirm assets are actually being generated correctly. Modify the script section of your RSpec jobs to include:

- bundle exec rake assets:precompile RAILS_ENV=test
# Confirm assets exist and have fingerprints
- ls -la public/assets | grep -E "application.*\.(css|js)"

This will fail fast if precompilation didn’t generate the expected files, saving you from debugging routing errors later.

4. Ensure Views Use Rails Asset Helpers #

Double-check that your views don’t use hardcoded paths like /assets/application.css. Always use Rails’ asset helpers:

# ✅ Correct
<%= stylesheet_link_tag 'application' %>
<%= javascript_include_tag 'application' %>

# ❌ Wrong (will break in CI due to fingerprinted assets)
<link rel="stylesheet" href="/assets/application.css">

Rails automatically inserts the fingerprinted filename (e.g., application-abc123.css) when using these helpers, which matches the precompiled files in CI.

5. Optimize CI Cache (Optional but Useful) #

Your current CI cache doesn’t include public/assets, so every job re-runs assets:precompile unnecessarily. Add it to the cache to speed up jobs:

cache:
  paths:
    - .bundle
    - vendor/
    - public/assets # Add this line

Why This Works #

• Local development uses the Rails asset pipeline to compile assets on-the-fly, so missing files are generated automatically.
• In CI, you precompile assets upfront, but the test environment was configured to not serve static files—fixing that lets the Rails server deliver the precompiled assets to Poltergeist.
• Setting Capybara.asset_host ensures the headless browser requests assets from the correct server address, avoiding relative path mismatches.

内容的提问来源于stack exchange，提问作者Michał Andros