-
Notifications
You must be signed in to change notification settings - Fork 9
Project Overview (Development)
The build system is written using sbt. It is composed of two projects:
Based on an AutoPlugin we have our own YarnPlugin. This defines commands for the webui project that can be seen in the autoImport
object inside the object YarnPlugin
.
This is Play project which also makes use of the DockerPlugin to push builds made on a branch to be pushed to dockerhub.
Broccoli uses Play 2.6.X at the time of writing this. The interface to the HTTP is managed through controllers. For communication other than the HTTP API we use the controller that is defined in WebsocketController. The data is structured in case classes that are placed in models. The logic for handling user requests is under services with the primary service being NomadService
that interacts with Nomad. There is an additional HTTP module for performing GET
requests to Nomad that is handled through the NomadHTTPClient. The storage for instances is configurable and can be configured to work with FileSystemStorage
or CouchDBStorage
. Currently, in production, we use FileSystemStorage
. The type of storage you want to use can be modified in application.conf
under play.modules
. See the reference.conf
for more details.
We use webpack for building the front end. It picks up the webui/src/index.js
and compiles it to a js file inside dist
. There are two configurations that we use for webpack. webpack.config.prod.js
is used for a normal build. If you want a development sessions with the webpack development server you can use the webpack.config.js
. The development configuration also defines a devServer
that runs on 8080 and forwards API requests to the Play server on localhost:9000
but serves javascript/css files through the webpack-dev-server
. This allows for hot loading frontend modules. The setup can be used using yarn start
from the webui directory.
We also use yarn as the package manager for the frontend. The package configurations are defined inside the package.json in webui
. Since we use Elm as a front end language the packages related to Elm are handled through elm-github-install
. The configuration for these packages is defined in elm-package.json
.
We use Elm as a frontend language. Currently, we are using version 0.18.x
. Elm follows an MVC pattern where we have the model, view and update (controller) functions. These defined inside Main.elm
. Since we use WebSockets for communication with Broccoli we also have an elm module that is handling WebSocket messages and applying correct decoders based on the message type. These are defined in Ws.elm
. The frontend also follows the same pattern as the backend for data objects being defined under models. Views are generated recursively with the bigger views like BodyView
encapsulating smaller views like InstanceView
which further encapsulate smaller views like the InstanceDetailView
etc.
Broccoli uses both unit and integration tests. Unit tests for the backend are using specs2. Unit tests for the front end use elm-test. It is generally recommended that for every function or change added to Broccoli there should be corresponding tests added to the backend and the frontend.
To use the integration tests we first build a docker image using the Dockerfile
in test/docker
. Once we have a built docker image we are ready to run the integration tests. The integration tests are currently defined in two ways. There are some integration tests that are defined through the sbt module IntegrationTest
that looks for tests under server/src/it/scala
. We have a docker context called the BroccoliDockerContext
that takes up the responsibility of spinning up and tearing down running instances of Nomad, Consul or Broccoli. The tests execute within the spawn and tear down functionality. The other integration tests are written under in http-api-tests
. These tests use simple curl commands to query broccoli and verify the result based on preconfigured text files. These are written in a simple format that is defined through the http-api-tests
library.
Since Cluster Broccoli is an open-source project it uses Travis for CI. The configuration for Travis builds is defined under travis.yml
. This includes building broccoli, running unit and integration tests, building the docker image and in case of commit to a branch pushing the docker image to docker hub. It is the responsibility of the developer and the reviewer to ensure that commits are not merged to master until all tests are green. Since the build is done in a step by step manner and docker is the last step, no image is pushed to docker until all tests are green.