Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DockerPlugin overwrites version #830

Closed
hseeberger opened this issue Jun 29, 2016 · 12 comments
Closed

DockerPlugin overwrites version #830

hseeberger opened this issue Jun 29, 2016 · 12 comments

Comments

@hseeberger
Copy link
Member

If you define version.in(Docker) := "latest", your version will also be "latest":

For some reason version delegates to docker:version:

[reactive-flows]> inspect version
[info] Setting: java.lang.String = latest
[info] Description:
[info]  The version/revision of the current module.
[info] Provided by:
[info]  {file:/Users/heiko/projects/scala/reactive-flows/}reactive-flows/docker:version
[info] Defined at:
[info]  /Users/heiko/projects/scala/reactive-flows/build.sbt:31
[info] Reverse dependencies:
[info]  docker:dockerTarget
[info] Delegates:
[info]  docker:version
...
@muuki88
Copy link
Contributor

muuki88 commented Jul 1, 2016

Can you provide a failing test as a pull request?

@hseeberger
Copy link
Member Author

How should I test this? Would a link to a GitHub project which shows this behavior also work?

@muuki88
Copy link
Contributor

muuki88 commented Jul 2, 2016

We have sbt scripted integration tests. One could inspect that setting a version in Docker doesn't affect version.

@muuki88
Copy link
Contributor

muuki88 commented Jul 3, 2016

I can't reproduce this with the test project in native-packager. What I did

First: Change the build.sbt in test-project-docker to contain

enablePlugins(JavaAppPackaging, DockerSpotifyClientPlugin)
name := "docker-test"

version := "0.1.0"
version in Docker := "latest"

maintainer := "Gary Coady <gary@lyranthe.org>"

Second. Fire up sbt and ; show version ; show docker:version. Printing the expected results.

@hseeberger
Copy link
Member Author

All right, the issue might be related to using sbt-git with GitPlugin.autoImport.git.useGitDescribe := true.

You can reproduce it with https://github.com/hseeberger/reactive-flows.

@muuki88
Copy link
Contributor

muuki88 commented Jul 6, 2016

Famous quote:

This is not a bug, it's a feature

You have no version := "x.y.z" setting in your build definition, so it seems sbt picks up the next best definition of version and uses it.

@muuki88 muuki88 closed this as completed Jul 6, 2016
@hseeberger
Copy link
Member Author

Have you seen that I'm using versionWithGit?

@hseeberger hseeberger reopened this Jul 6, 2016
@hseeberger
Copy link
Member Author

I wanted to say useGitDescribe, see project:Build.scala.

@muuki88
Copy link
Contributor

muuki88 commented Jul 6, 2016

Then there seems to be a conflict between these two plugins. Setting a concrete version works :/

@hseeberger
Copy link
Member Author

All right, I have investigated the issue. sbt-native-packager (at least JavaAppPackaging) seems to overwrite the version of each project:

> inspect version
[info] Setting: java.lang.String = 0.1-SNAPSHOT
[info] Description:
[info]  The version/revision of the current module.
[info] Provided by:
[info]  {file:/Users/heiko/tmp/version-issue/}version-issue/debian:version
[info] Defined at:
[info]  (com.typesafe.sbt.packager.debian.DebianPlugin) DebianPlugin.scala:94

sbt-git on the other hand sets the version.in(ThisBuild), hence sbt-native-packager wins.

The workaround is setting the version accordingly: version := version.in(ThisBuild).

@hseeberger
Copy link
Member Author

I think this is rather an issue of sbt-git by using the build settings rather than the project settings. Sorry for the noise!

@muuki88
Copy link
Contributor

muuki88 commented Jul 7, 2016

No problem 😉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants