Adding support for additional docker commands

[drdozer]

I've started work on adding support for other docker commands for controlling containers. This is a pull request to let you see what I'm doing. Not expecting it to be merged in at this time.

[drdozer]

So it supports syntax like this for configuring container creation:

  createOptions in docker := new CreateOptions {
    image("mysql")
    expose(22)
    port("0.0.0.0", 3306, 3306)
    port("0.0.0.0:9022:22")
  }

[drdozer]

Start is now implemented. Create and start can be chained like this:

  startOptions in docker := new StartOptions {
    val containerId = (dockerCreate in docker).value
    container(containerId)
  }

[drdozer]

Here's an example, not very exciting workflow:

  createOptions in docker := new CreateOptions {
    image("mysql")
    expose(22)
    port("0.0.0.0", 3306, 3306)
    port("0.0.0.0:9022:22")
    env("MYSQL_RANDOM_ROOT_PASSWORD" -> "true")
  },

  startOptions in docker := new StartOptions {
    val containerId = (dockerCreate in docker).value
    container(containerId)
  },

  stopOptions in docker := new StopOptions {
    val containerId = (dockerStart in docker).value
    container(containerId)
  },

  rmOptions in docker := new RmOptions {
    val containerId = (dockerStop in docker).value
    container(containerId)
  }

[drdozer]

OK, the issue I've hit is that MySQL encodes usnernames and passwords into the URL and calls

scala.slick.codegen.SourceCodeGenerator.main(
  Array(slickDriver, jdbcDriver, url, outputFolder, pkg)

Postgres seems to want to have the username and password passed in separately and requires the call

scala.slick.codegen.SourceCodeGenerator.main(
  Array(slickDriver, jdbcDriver, url, outputFolder, pkg, usr, pwd)

I can put some special case code in slickGenTables to switch on mysql/postgres but that seems a bit icky to me. Or I could pull the logic for generating that Array() into the database-dependent codegen object?

[marcus-drake]

This looks interesting.
The configuration DSL looks cool at first sight :)

I'm a bit curious of your use cases for it.
Are there cases when you want to start several containers?

[drdozer]

My immediate use is to spin up/down databases with schemas for slick table generation. But we have a whole host of builds that require some tools or infrastructure to build against and we're moving towards dockerising all these. So dockerising making these tools available to the builds is a logical next step.

[drdozer]

So in another project, we generate code against an RDF schema stored in a triple store. The build requires the populated triplestore to be available. Spinning up the populated triplestore when we need it during the build would let us build anywhere, rather than on a specially configured host.

[drdozer]

@marcuslonnberg what do you think to adding logic to alternatively only run a docker build if something has changed?

[marcus-drake]

Sorry I haven't had time to follow up on this. My company have moved to a new office and such.

I'm thinking about the complexity of this configuration and how often it will be used.
I would like to know if this could be supported by giving the users access to a Docker client where they can run whatever docker commands they want by defining their own tasks.
For example if you want to start a database for Slick table generation then you can define a task which starts the container:

val startDatabase = taskKey[ContainerId]("...")
startDatabase := {
    dockerClient.run(port = 1234, image = "postgres", name = "db")
}

val stopDatabase = taskKey[ContainerId]("...")
stopDatabase := {
    dockerClient.stop(name = "db")
}

I feel like the configuration DSL is both powerful but at the same time limited by how tasks and settings work in sbt.

[drdozer]

I've actually been thinking about this also. One alternative I'd come up with was to wrap an existing command in a docker spin-up-tear-down cycle. So:

withDockerInstance(someTask) { configurationDSLCommands }

That would spin up the instance, then run someTask, then tear it down. That would let you spin up one instance for code generation, another instance for testing, and so on.

[13h3r]

I like the idea. What about supporting tag and push command?

[13h3r]

Ignore my comment. I read the docs carefully and found all I need. Sorry

[vishalovercome]

Are there any plans to merge this PR? The ability to remove an image would allow us to drive our CI using sbt alone. If this pull request is very extensive, then I can implement just that feature alone