gitscalasbtsbt-git

Versioning does not increment automatically

I am using https://github.com/sbt/sbt-git to get the benefit of automatic versioning as descript in the section Versioning with Git.

My build.sbt file looks as the following: 

version := "0.1.0"

scalaVersion := "2.12.8"

scalacOptions ++= Seq(
  "-encoding", "UTF-8", // source files are in UTF-8
  "-deprecation", // warn about use of deprecated APIs
  "-unchecked", // warn about unchecked type parameters
  "-feature", // warn about misused language features
  "-language:higherKinds", // allow higher kinded types without `import scala.language.higherKinds`
  "-Xlint", // enable handy linter warnings
  "-Xfatal-warnings", // turn compiler warnings into errors
  "-Ypartial-unification" // allow the compiler to unify type constructors of different arities
)

scalacOptions in(Compile, console) ~= {
  _.filterNot(Set("-Xlint"))
}

libraryDependencies ++= Seq(
  "org.typelevel" %% "cats-core" % "1.6.0",
  "ch.qos.logback" % "logback-classic" % "1.2.3",
  "com.typesafe.scala-logging" %% "scala-logging" % "3.9.2"
)

libraryDependencies ++= Seq(
  "org.scalacheck" %% "scalacheck" % "1.14.0" % "test",
  "org.scalactic" %% "scalactic" % "3.0.6" % "test",
  "org.scalatest" %% "scalatest" % "3.0.6" % "test"
)

libraryDependencies ++= Seq(
  "com.typesafe.akka" %% "akka-slf4j" % "2.5.22",
  "ch.qos.logback" % "logback-classic" % "1.2.3"
)

libraryDependencies += "com.dimafeng" %% "testcontainers-scala" % "0.25.0" % "test"


enablePlugins(JavaServerAppPackaging)
enablePlugins(DockerPlugin)
enablePlugins(GitVersioning)
dockerExposedPorts := Seq(8080)
git.formattedShaVersion := git.gitHeadCommit.value map { sha =>
  s"$sha".substring(0, 7)
}

dockerUpdateLatest := true
dockerAlias := DockerAlias(None, Some("zerocoder"), (packageName in Docker).value, git.gitDescribedVersion.value)

After the commit, it does not increment from version "0.1.0" to "0.2.0" automatically.

What am I doing wrong?

Solution

  • The short answer is:

    1. Remove / leave out the explicit setting version from your build.sbt file (i.e this statement version := "0.1.0")
    2. Create a git tag to set the desired version (prefixed by v), see the doc, for instance
    >git tag -a v0.2.0  -m "my version 0.2.0"

    You can then see the version set by the plugin, by running:

    >sbt version
// Displays
// [info] 0.2.0

    Here is a bit of explanation:

    So the way sbt-git works, is that it sets the version of your sbt build for you (the one that you get as a result of a running sbt version). To do so, it follows several rules, here are the 2 first:

    1. Looks at version-property setting (default to project.version), and checks the sys.props to see if this has a value. If so, use it.
    2. Otherwise, looks at the project tags. The first to match the gitTagToVersionNumberSetting is used to assign the version. The default is to look for tags that begin with v and a number, and use the number as the version. If there are multiple version tags, it will pick the highest.

    So in your case, because you set explicitly the project version to 0.1.0 in your build.sbt, what you would get as a result of running sbt version is 0.1.0. Even after doing some commits the value of sbt version would still be 0.1.0 because the rules one would apply (as long as the version is set in your build.sbt). Note that the plugin doesn't change the value set in that file, it only uses it, when it's defined.

    If you were to remove that line (version := "0.1.0"), then rule 2 would apply, which in a nutshell look up the tag and return the first one to match gitTagToVersionNumberSetting which by default is a string that begin with v and followed by a number.

    So essentially to get your project set to version 0.2.0 using the plugin, you would have to create a tag on top of the head commit v0.2.0, (running git tag -a v0.2.0 -m "my version 0.2.0", for instance).

    And as you develop your project, several commits would be added, leading up to your version 0.3.0 (or 0.2.1), and once you create the corresponding tag on top of the latest commit - let's say the tag v0.3.0 - then the plugin would pick that up (applying the rule 2) and use it to set it as version of your project (that you could see by running sbt version, as said previously).

    This is a flow you would use basically to make your project version follow you your (git) tags version.