Programming language: Scala
License: GNU General Public License v3.0 or later
Tags: Misc    
Latest version: v1.0.9

service-chassis alternatives and similar packages

Based on the "Misc" category.
Alternatively, view service-chassis alternatives based on common mentions on social networks and blogs.

Do you think we are missing an alternative of service-chassis or a related project?

Add another 'Misc' Package


Current Release Version


Compatible with sbt 1.3.x

Commit Messages

see git-commit for an acceptable commit message structure


  • gitflow with default options git flow init -d
  • compile and test sbt clean compile test
  • run sbt run and then goto http://localhost:8080/health
  • create docker image ** sbt docker
  • create a docker image and push to remote registry ** sbt dockerBuildAndPush
  • delete dangling docker images sbt removeDangling
  • release ** sbt release
  • publish to s3 sbt publish
  • generate dependency graph sbt dependencyTree
  • run local docker image docker run -p 8080:8080 {ID} where {ID} is the image id. To check that the service is up and running, goto http://localhost:8080/health

** see details below

Chassis Documentation



The following sbt plugins are used

  • Git sbt-git

    Allows us to retrieve information about the commit such as the sha or the branch which is used to enhance the BuildInfo object

  • BuildInfo buildinfo

    configured to generate a BuildInfo object on compile with

    • name
    • version
    • scalaVersion
    • sbtVersion
    • git.gitCurrentBranch
    • git.gitHeadCommit

    This information will be used to enhance the detailed health endpoint

  • GitFlow sbt-git-flow

    The gitflow plugin extends the release plugin and as such maintains the versioning in the ./version.sbt file see sbt-release for more release options the sbt-assembly plugin is used to generate the fat jar in this pipeline see (git-flow-cheatsheet)[http://danielkummer.github.io/git-flow-cheatsheet/)

  • Docker sbt-docker

    docker image naming convention is configured based on the fact that with gitflow we have two primary branches, master and develop It looks for an environment variable ${BRANCH_NAME}. If missing, its assumed that the docker image is being built for local testing

    Naming convention used:

    • no BRANCH_NAME -> organization/name:latest
    • develop -> registry/name:version-sha
    • master -> registry/name:version

    registry is the remote registry where the image is to be pushed version is develop will be Major.Minor.Patch-Snapshot

  • Dependency Graph sbt-dependency-graph

    To generate dependency graph

  • Format scalafmt-github

    see scalafmt for details

  • Style scalastyle

    see scalastyle-github for details

  • s3 Resolver fm-sbt-s3-resolver s3 will be used to host the snapshot and release jars


Uses gh-pages branch

jekyll serve --watch