One of the sbt plugins fails for a detached head

[matanox]

Not really a bug, but if .git is removed after cloning https://github.com/allenai/pipeline, or it is being used as a git submodule rather than cloned, then one of the sbt plugins brought in causes this:

java.lang.RuntimeException: Setting value cannot be null: {file:/..../pipeline/}/*:gitCurrentBranch
    at scala.sys.package$.error(package.scala:27)
    at sbt.EvaluateSettings$INode.setValue(INode.scala:143)
    at sbt.EvaluateSettings$MixedNode.evaluate0(INode.scala:175)
    at sbt.EvaluateSettings$INode.evaluate(INode.scala:135)
    at sbt.EvaluateSettings$$anonfun$sbt$EvaluateSettings$$submitEvaluate$1.apply$mcV$sp(INode.scala:69)
    at sbt.EvaluateSettings.sbt$EvaluateSettings$$run0(INode.scala:78)
    at sbt.EvaluateSettings$$anon$3.run(INode.scala:74)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)
[error] Setting value cannot be null: {file:/..../pipeline/}/*:gitCurrentBranch

How would you go about determining the "offending" plugin if you wanted to file a bug with it? Thanks!
I think other than grepping all the sources of all sbt projects there'd be no way. Maybe you know better, or might have a good guess.

[matanox]

Please ignore, an sbt-git bug.

[markschaake]

@matanster I'm trying to migrate our test projects to use sbt-scripted and just hit the same error (for a scripted build). Did you discover a workaround?

[matanox]

Not really. I commented in sbt/sbt-git#97 (comment), but frankly no longer sure whether it crashes in sbt-git code, or in some other plugin that uses sbt-git api, or even plain code that uses the plugin's api, whichever might be the case here.

[matanox]

@markschaake you'd probably not believe how much this complicates deployment to OpenShift platform-as-a-service, where this pops up.

It may seem like as long as allenai/sbt-plugins requires git being available in the environment, I am unable to deploy a fork of allenai/pipeline to OpenShift as part of my project. This is because like some other PaaS, the default deploy process builds the projects from source, hence deploying entails building ― which requires git, and that is impossible if code or plugins require git in the runtime ― without graceful fallback.

I'll pluck out allenai/pipeline, or wrangle a more perverted deploy meanwhile :) or publish my fork on every change.

However I can see why building should require git, because that opens up for a more intelligent deploy process, so I'd not remove the dependency, especially not for pipeline, where it can further be leveraged at runtime to version data by the git commit (as an enhancement).

In case you got down here alive, thanks.

[jkinkead]

Our deploy system is pretty crufty - and I say that as the primary author of it. :)

We have vague plans to do something more clever with it this year - I think everyone would be happier with an artifact-based approach (build -> publish deploy artifact; deploy a given artifact as two separate steps).