dockerAlias should be a Task instead of Setting

[kovszilard]

Problem

dockerAlias and dockerAliases are defined as SettingKeyss.

When building docker images I would like to dynamically generate tags based on the Git status. For example

• if the project has no changes, I would like to use the current commit hash
• if the project has uncommitted changes, I would like to use the current commit hash + "-dirty"

Because setting values are determined when SBT loads, project changes cannot be captured in dockerAlias and dockerAliases.

Solution

Define dockerAlias and dockerAliases as TaskKeys.

[muuki88]

Hi @kovszilard

Thanks for your well reasoned feature request :smiley:

In general I don't mind changing settings to tasks. I have no clue if this has any performance or other implications, so meh. However I'm not sure if this change would be binary compatible. If it's not, then I would refrain from doing this.

Just to understand your workflow. You are constantly building docker images in your regular development workflow? I'm asking because this sounds very time consuming :grin: Have you considered using a special tag for development? Something like

dockerAlias :=  dockerAlias.value.copy(tag = ("dev.docker.alias"))

[kovszilard]

Hi @muuki88

Yes, I create containers as my normal development workflow. I tag my containers with git commit hashes. We do the same in production.

Sometimes I run these containers locally, sometimes I push them to a remote repository and start them on a remote server. I don't want to accidentally push a tag to the remote repository if that image came from some uncommitted changes. This is why I would like to attach "-dirty" postfix to the tag. So even if I accidentally push this commit, I won't overwrite some existing tag.

My goal is to have the same SBT config on the CI env and locally too. If I modify dockerAlias on my local dev env, then I will end up having two configurations.

I'm not an SBT expert therefore I'm not sure about the performance implications.

What are your concerns regarding binary compatibility? Would you accept a PR with the changes?

[muuki88]

Sometimes I run these containers locally, sometimes I push them to a remote repository and start them on a remote server. I don't want to accidentally push a tag to the remote repository if that image came from some uncommitted changes

Ah :bulb: . If remote repositories are involved things get a bit more messy, I get that.

Another workaround for this issue would be reloading sbt and the publishing, e.g.

> ; reload ; Docker / publishLocal

This regenerates the setting keys. However you need to define the dockerAlias with some external command and can't use any existing sbt tasks :cry:

What are your concerns regarding binary compatibility?

If things are binary compatible, I'm fine with the change and happily accept a PR :smile: . If not this may break builds for users when they use plugins that depend on sbt-native-packager and thus can't upgrade due to a binary incompatible change.