-
Notifications
You must be signed in to change notification settings - Fork 441
Development Environment Overview
This page is a detailed description of our docker
based development environment. For and introduction how to use it check out our contribution guide.
There are many different docker
images and docker compose
services that our development environment is based upon.
This image is the basis of all the other images. It adds our repositories, installs shared packages and sets up our user on top of our operating system (openSUSE Leap).
This image installs all packages and sets up the configuration needed to run the OBS backend on top of the base image. It is used to run the backend
and worker
services with docker-compose
. This image needs to be changed if the backend has as new dependency or configuration.
This image installs all the packages needed to run memached
on top the base image and is used to run the cache
service with docker-compose
. This image only needs to be changed if want to run memcached
differently.
This image installs the mariadb
package on top the base image and is used to run the db
service with docker compose
. This image only needs to be changed if want to run mariadb
differently.
This image installs all packages needed for our ruby on rails
app on top of the base image. Additionally it serves as a kind of cache for the gem bundle
. This image gets automatically rebuild on every commit by the docker
hub so the gem bundle
cache is up to date.
The frontend
image is a thin layer on top of the frontend-base image that makes sure different users can run the ruby on rails
app with their own user id. Mostly, so it does not generate log files, assets etc. in the git checkout with some strange user id. It is used to run the frontend
service with docker-compose
.
This image needs to be rebuild every time the gem bundle
changes.
This image is different to all other images. It is build by every developer, so it can pick up their user id, and is not on the docker
hub.
Available services in our development environment are:
- db
- cache
- backend
- worker
- frontend
Where it makes sense they expose their service also to your host machine so you can inspect the services with the standard tools. For instance you can connect to the db service via the standard SQL tools on localhost:3306.
The services also have their dependencies defined so they will bring up everything they need. For instance the worker will start a backend, if it isn't running.
- Development Environment Overview
- Development Environment Tips & Tricks
- Spec-Tips
- Code Style
- Rubocop
- Testing with VCR
- Authentication
- Authorization
- Autocomplete
- BS Requests
- Events
- ProjectLog
- Notifications
- Feature Toggles
- Build Results
- Attrib classes
- Flags
- The BackendPackage Cache
- Maintenance classes
- Cloud uploader
- Delayed Jobs
- Staging Workflow
- StatusHistory
- OBS API
- Owner Search
- Search
- Links
- Distributions
- Repository
- Data Migrations
- next_rails
- Ruby Update
- Rails Profiling
- Installing a local LDAP-server
- Remote Pairing Setup Guide
- Factory Dashboard
- osc
- Setup an OBS Development Environment on macOS
- Run OpenQA smoketest locally
- Responsive Guidelines
- Importing database dumps
- Problem Statement & Solution
- Kickoff New Stuff
- New Swagger API doc
- Documentation and Communication
- GitHub Actions
- How to Introduce Software Design Patterns
- Query Objects
- Services
- View Components
- RFC: Core Components
- RFC: Decorator Pattern
- RFC: Backend models