Skip to content

Development Environment Tips & Tricks

Dani Donisa edited this page Jan 11, 2024 · 40 revisions

This page is collection of tips & tricks about our development environment. For and introduction how to setup the development environment check out our contribution guide.

This will not and can not replace docker and docker-compose documentation. You are strongly encouraged get familiar with those tools!

Control services

You can bring up/tear down services

  • docker compose up -d
  • docker compose stop backend
  • docker compose restart

check their status

docker compose ps

or view the output of services

docker compose logs

Rebuild the frontend image

If you need to update the frontend service you can rebuild your local image with

docker compose build --pull frontend

Run commands in service

You can run any command in a service by calling exec. This command needs two parameters, the service you want to use and the command you want to execute.

docker compose exec frontend hostname

Attach to a running service

You can also start an interactive shell inside the service and run any command you like from it.

docker compose exec frontend /bin/bash -l

Test Suites

Be sure to have the seeds in your test database with RAILS_ENV=test bundle exec rake db:seed.

If you want to start with a fresh test database, run RAILS_ENV=test bundle exec rake db:reset db:seed.

Run RSpec

Run all specs

docker compose exec frontend rspec

or just a single spec

docker compose exec frontend rspec spec/models/package_spec.rb

Run feature spec for mobile (small devices)

While working on feature specs, by default the tests are running for desktop (large viewport). If you want to run it for mobile (small viewport), you need to set the environment variable CAPYBARA_DRIVER to mobile.

  • docker compose exec frontend /bin/bash -l
  • CAPYBARA_DRIVER=mobile rspec spec/feature/beta/something_spec.rb

Run Minitest

You can run all tests (including spider)

docker compose -f docker-compose.yml -f docker-compose.minitest.yml run --rm minitest bundle exec rake test

Run a single test file

docker compose -f docker-compose.yml -f docker-compose.minitest.yml run --rm minitest bundle exec ruby test/mytest_test.rb

Or run a single test from a test file

docker compose -f docker-compose.yml -f docker-compose.minitest.yml run --rm minitest bundle exec ruby test/mytest_test.rb -n test_method_name

Run Linters

docker compose run --rm frontend rake dev:lint:all

More details on RuboCop here.

Create data to play with in development

This will create some projects, a submit request, an interconnect to build.o.o and a maintenance project.

docker compose run --rm frontend rake dev:test_data:create

Use FactoryBot

If you need some random objects to play around, you can use our factories. For this you can include the FactoryBot syntax on a rails console and use all the commands you usually use in rspec.

  include FactoryBot::Syntax::Methods
  create_list(:package_with_file, 100)

Debugging

Debugging a spec with pry

  1. Add binding.pry to some spec
  2. docker compose run --rm frontend rspec spec/mixins/statistics_calculations_spec.rb

Debugging the rails app with pry

Debugging the running rails application will start the pry session in the rails output so you need to start the rails server on it's own.

  1. docker compose run --rm --service-ports frontend bash -c "bundle exec rake ts:start && bundle exec rails s -b 0.0.0.0"
  2. Add binding.pry to some code path
  3. Access your code path and pry will run

Reset your Environment

(Re)create your database

docker compose run --rm frontend rake db:drop dev:bootstrap

Remove images

You can remove a single image

docker image rm openbuildservice/frontend-base

or all of them

docker image prune

Reset everything and start from scratch 💣

Sometimes you just have to go back to where you have started....

  1. docker compose stop
  2. docker compose rm
  3. docker image prune -a
  4. rake docker:build
  5. docker compose up

Troubleshooting

Stale Rails server pid file

The frontend fails to start and you see a message like

frontend_1  | 09:25:14 web.1     | A server is already running. Check /obs/src/api/tmp/pids/server.pid.
...
openbuildservice_frontend_1 exited with code 1

That can happen if a docker instance forcefully get's shut down and thus doesn't clean up properly. To solve this delete the pid file with

rm  src/api/tmp/pids/server.pid

The bundle is outdated

The frontend fails to start and you see a message like

frontend_1  | 10:53:17 web.1     | /usr/lib64/ruby/gems/2.4.0/gems/bundler-1.13.6/lib/bundler/definition.rb:179:in
`rescue in specs': Your bundle is locked to mail (2.7.0), but that version could not be found in any of the sources
listed in your Gemfile. If you haven't changed sources, that means the author of mail (2.7.0) has removed it. You'll 
need to update your bundle to a different version of mail (2.7.0) that hasn't been removed in order to install. 
(Bundler::GemNotFound)
...
openbuildservice_frontend_1 exited with code 1

That can happen if you or someone else changed our bundle by updating a gem version or introducing a new gem. You have to bundle install again in your frontend container. You can do this simply by

docker compose up --build

Error in Sphinx

The frontend fails to start and you you get the following error trying to create objects via console:

Traceback (most recent call last):
        2: from (irb):1
        1: from app/mixins/populate_sphinx.rb:5:in `populate_sphinx'
ThinkingSphinx::ConnectionError (Error connecting to Sphinx via the MySQL protocol. Can't connect to MySQL server on '127.0.0.1' (115))

Please make sure that you didn't start the frontend with docker compose up but with the following command:

docker compose run --rm --service-ports frontend bash -c "(bundle exec rails sphinx:start_for_development &) && rails s -b 0.0.0.0"

Be sure to have the latest Thinking Sphinx configuration.

Long Startup Time for RSpec

Running specs in RSpec might take minutes before finally starting. This can be caused by the strategy used by DatabaseCleaner. As the time of writing, we use truncation. This strategy can be slow depending on the filesystem you use. Switching the strategy to deletion can greatly decrease the time it takes for RSpec to start running specs.

Recommended strategy depending on the filesystem you use:

  • deletion for ext4
  • truncation for btrfs

Your experience might differ, so be sure to give both strategies a try.

Clone this wiki locally