Single source of truth (sbt vs HOCON vs YAML)

[dwijnand]

I applaud this effort, but I wanted to check whether it honours having a single source of truth or not.

Doesn't project-info.scala-versions run the risk of disagreeing with both crossScalaVersion in ThisBuild in the sbt build state and the values in the scala key in .travis.yml?

For sbt vs Travis CI single-source of truth, I created https://github.com/dwijnand/sbt-travisci which uses Travis CI's configuration in .travis.yml to define crossScalaVersion in ThisBuild for sbt (as well as a few other things).

In absense of "reactive files" (i.e FUSE-backed files) we'll have to make the HOCON file this project introduces (project/project-info.conf) to source of truth for them, and then read them into the sbt build state with a plugin. Does (or will) this project cover that need?

[jroper]

I'm wondering how much of this info can be extracted from sbt already? We already need to put a lot of this info in the sbt file if we publish to Maven central (eg, issue tracker). Perhaps if this info was provided via sbt configuration keys provided by this plugin, then the hocon file could just be a generated artifact, and the plugin could also automatically add this to the Maven pom extra configuration.

[ennru]

I'm all for collecting the information from where it originates.
For the Scala versions the values in project-info.conf overwrite the values from sbt's crossScalaVersion. In case you don't use that mechanism to build with multiple Scala versions.
Extracting it from CI is a good idea, as well. If there is a good precedence rule.

@jroper Yes, I thought about putting it in sbt directly. This gave me a better turnaround and to have most of the information outside of sbt has value, I think.

I guess we can take it from here? PRs welcome.