Giters

sbt / sbt-buildinfo

I know this because build.sbt knows this.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Some keys get silently dropped from output

ryan-williams opened this issue · comments

commented

The example from the README works for me:

BuildInfoKey.map(name) { case (k, v) => "project" + k.capitalize -> v.capitalize }

but if I try e.g.:

BuildInfoKey.map(moduleID) { case (k, v) ⇒ "projectMod" -> v.name }

I get no errors or warnings, but there is no projectMod key/value in the output.

Why might this be?

commented

what version? for example, is this a regression in 0.9.0?

commented

Sorry, I believe I just observed this with 0.8.0 and 0.9.0.

One theory I have is that something is "wrong" with moduleID as a settingKey; I can't enter it in the SBT repl, for reasons unknown to me:

sbt:lib> projectID
[info] lib:lib:0.1.0-SNAPSHOT
sbt:lib> moduleID
[error] Not a valid command: moduleID
[error] Not a valid project ID: moduleID
[error] Expected ':'
[error] Not a valid key: moduleID (similar: moduleName, moduleGraph, ivyModule)
[error] moduleID
[error]         ^

Still, if some keys are indeed "off-limits", buildinfo shouldn't just silently fail.

Any context about any of this is appreciated.

I can try to make a smaller repro case if it really isn't expected that things like this would ever happen; I somewhat expected the answer to be that there is something about how BuildInfo gets keys and values, or intrinsic differences between keys, that would explain this behavior.

commented

One theory I have is that something is "wrong" with moduleID as a settingKey; I can't enter it in the SBT repl, for reasons unknown to me

yes, looks like moduleID is unset in general, and set in specific places:

but it's constructed (see the first 2 instances) from projectID, so you should be able to use that.

Still, if some keys are indeed "off-limits", buildinfo shouldn't just silently fail.

agreed. clearly.

Any context about any of this is appreciated.

I can try to make a smaller repro case if it really isn't expected that things like this would ever happen; I somewhat expected the answer to be that there is something about how BuildInfo gets keys and values, or intrinsic differences between keys, that would explain this behavior.

hopefully that give some context and explains some of the behaviour.

commented

I've configured SBT like this:

def thisProject(scope: Scope): Scope = Scope.subThisProject(scope)
def buildinfoSettings(scope: Scope): Seq[Setting[_]] =
  Seq(
    buildInfoPackage in thisProject(scope) := "build",
    buildInfoKeys    in thisProject(scope) :=
      Seq[BuildInfoKey](
        organization        in thisProject(scope),
        name                in thisProject(scope),
        version             in thisProject(scope),
        scalaVersion        in thisProject(scope),
        sbtVersion          in thisProject(scope),
        baseDirectory       in thisProject(scope),
        resourceDirectory   in thisProject(scope),
        resourceDirectories in thisProject(scope),
        sourceManaged       in thisProject(scope),
        resourceManaged     in thisProject(scope),
      ))

and I've got BuildInfo.scala like this below, which misses keys resourceDirectory and resourceDirectories:

package build

import scala.Predef._

/** This object was generated by sbt-buildinfo. */
case object BuildInfo {
  /** The value is "company". */
  val organization: String = "company"
  /** The value is "proj-core". */
  val name: String = "proj-core"
  /** The value is "0.1.0-SNAPSHOT". */
  val version: String = "0.1.0-SNAPSHOT"
  /** The value is "2.12.7". */
  val scalaVersion: String = "2.12.7"
  /** The value is "1.2.3". */
  val sbtVersion: String = "1.2.3"
  /** The value is new java.io.File("/home/rgomes/workspace/proj/proj-core"). */
  val baseDirectory: java.io.File = new java.io.File("/home/rgomes/workspace/proj/proj-core"),
  /** The value is new java.io.File("/home/rgomes/workspace/proj/proj-core/target/scala-2.12/src_managed"). */
  val sourceManaged: java.io.File = new java.io.File("/home/rgomes/workspace/proj/proj-core/target/scala-2.12/src_managed")
  /** The value is new java.io.File("/home/rgomes/workspace/proj/proj-core/target/scala-2.12/resource_managed"). */
  val resourceManaged: java.io.File = new java.io.File("/home/rgomes/workspace/proj/proj-core/target/scala-2.12/resource_managed")
  override val toString: String = {
    "organization: %s, name: %s, version: %s, scalaVersion: %s, sbtVersion: %s, sourceManaged: %s, resourceManaged: %s" format (
      organization, name, version, scalaVersion, sbtVersion, sourceManaged, resourceManaged
    )
  }
}

I've double checked to see whether my submodule proj-core contains the missing keys. Yes. it does:

sbt:proj> show proj-core/resourceDirectory
[info] /home/rgomes/workspace/proj/proj-core/src/main/resources
sbt:proj> show proj-core/resourceDirectories
[info] * /home/rgomes/workspace/proj/proj-core/src/main/resources
[info] * /home/rgomes/workspace/proj/proj-core/target/scala-2.12/resource_managed/main

I've tested with:

  • SBT version 1.2.3
  • sbt-buildinfo versions 0.7.0, 0.8.0 and 0.9.0
    I was initiallly using version 0.7.0 but I've observed the very same behavior on versions 0.8.0 and 0.9.0.