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

Wrap docker labels with " character #1014

Merged
merged 4 commits into from
Aug 21, 2017
Merged

Conversation

kimxogus
Copy link
Contributor

Issue

For now, dockerLabels doesn't generate labels with wrapping " character.

  • build.sbt
dockerLabels := Map("foo" -> "bar")
  • Generated Dockerfile
LABEL foo=bar

This may have issue with string values with spaces

  • build.sbt
dockerLabels := Map("fooBar" -> "foo bar")
  • Generated Dockerfile
LABEL fooBar=foo bar

Fix

Fixed that to wrap with " character.

  • build.sbt
dockerLabels := Map("fooBar" -> "foo bar", "number" -> 123)
  • Generated Dockerfile
LABEL fooBar="foo bar"
LABEL number=123

Also, dockerLabels will accept map containing any type of value and make them string automatically(for convenience).
Only Number typed values won't be wrapped with " character

@lightbend-cla-validator

Hi @kimxogus,

Thank you for your contribution! We really value the time you've taken to put this together.

Before we proceed with reviewing this pull request, please sign the Lightbend Contributors License Agreement:

http://www.lightbend.com/contribute/cla

Copy link
Contributor

@muuki88 muuki88 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the very well crafted and documented pull request.

I have concerns about the number/string separation. I found no clues in the link you posted and would rather wrap everything in ".

val (variable, value) = label
Cmd("LABEL", s"${variable}=${value}")
val valueString = value match {
case n: Number => n.toString
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why the special case for numbers? I haven't found an example that highlights
a special behavior?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, I scanned Dockerfile docs again and it seems not to be needed. I'll change it to wrap everything in ".

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awesome :)

@@ -31,7 +31,7 @@ trait DockerKeys {
val dockerExecCommand = SettingKey[Seq[String]]("dockerExecCommand", "The shell command used to exec Docker")
val dockerBuildOptions = SettingKey[Seq[String]]("dockerBuildOptions", "Options used for the Docker build")
val dockerBuildCommand = SettingKey[Seq[String]]("dockerBuildCommand", "Command for building the Docker image")
val dockerLabels = SettingKey[Map[String, String]]("dockerLabels", "Labels applied to the Docker image")
val dockerLabels = SettingKey[Map[String, Any]]("dockerLabels", "Labels applied to the Docker image")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any is not a good type here. If the number/string separation is really necessary I would rather map this into a separate ADT. We then need to introduce implicit conversions to not break existing builds.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok

Copy link
Contributor

@muuki88 muuki88 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Thanks :)

@muuki88 muuki88 merged commit 83b4ddd into sbt:master Aug 21, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants