Awesome

Release Information

Latest version : 1.0.16

Releases

"allawala" %% "service-chassis" % {version}

Snapshot

"allawala" %% "service-chassis" % {version-SNAPSHOT}

Resolvers

resolvers += "Service Chassis Snapshots" at "https://s3-ap-southeast-2.amazonaws.com/maven.allawala.com/service-chassis/snapshots"
resolvers += "Service Chassis Releases" at "https://s3-ap-southeast-2.amazonaws.com/maven.allawala.com/service-chassis/releases"

Commit Messages

see git-commit for an acceptable commit message structure

QUICK START

• 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 locally sbt publishLocal
• 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

Documentation

Details

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

NOTE

• Running via sbt will not pickup the logback file or the buildinfo as compile -> package step filters them out (see build.sbt)

Documentation

Uses gh-pages branch

jekyll serve --watch