BuildInfoBuildNumber is incremented on 'sbt run' about sbt-buildinfo HOT 4 CLOSED

+1

from sbt-buildinfo.

Here's a snippet from inspect tree run:

sbt-buildinfo> inspect tree run
[info] compile:run = InputTask[Unit]
[info]   +-runtime:full-classpath = Task[scala.collection.Seq[sbt.Attributed[java.io.File]]]
[info]   | +-runtime:exported-products = Task[scala.collection.Seq[sbt.Attributed[java.io.File]]]
[info]   | | +-runtime:products = Task[scala.collection.Seq[java.io.File]]
[info]   | | | +-compile:compile = Task[sbt.inc.Analysis]
[info]   | | | +-compile:compile-inputs = Task[sbt.Compiler$Inputs]
[info]   | | | +-compile:copy-resources = Task[scala.collection.Seq[scala.Tuple2[java.io.File, java.io.File]]]
[info]   | | | 
[info]   | | +-compile:package-bin = Task[java.io.File]
[info]   | | +-*/*:export-jars = false
[info]   | | +-compile:compile = Task[sbt.inc.Analysis]
[info]   | | 

Note compile:run depends on compile:compile. compile:compile in turn depends on compile:sources, which depends on compile:managed-sources, which depends on compile:source-generators.
In other words, each run is calling compile first.

One way to prevent it may be to check the modified time or hash of all source files, and increment only when something is changed. That's a world of hurt that you wouldn't want to be in since it'll introduce unpredictable I/O.
I can open up buildNumberTask, and also add a parameter called increment which would take 1 for my implementation. If you want to implement your own strategy for not incrementing the number you can conditionally pass in 0.

from sbt-buildinfo.

0.2.3-SNAPSHOT is out with this change.

from sbt-buildinfo.

Is there a regression in 0.3.2 in this?

from sbt-buildinfo.