Commands vs tasks about sbt-docker-compose

[kurtkopchik]

Hi @s-nel, great question!

It was a while ago so you are testing my memory a bit but I recall during the initial implementation I starting out using Tasks but did run into some cases where I couldn't get it accomplish what I needed and had to switch over to using Commands. I'm not sure if this is the only class of problem I hit with Tasks but I believe that the main issue had to do with not being able to call a Task as a step from within another Task. You could make a Task depend on another Task but you couldn't perform some logic and then decide whether to call a specific other Task or not. Whereas with a Command I could call out and execute another Task or Tasks from anywhere within it.

For example, in the composeTestRunner Command if you pass in the Id of a running instance the code will run tests against the running instance you specified and leave it running. If you do not supply an instance Id it will run docker Task to build a new image, run your tests, and then stop the container. I wouldn't be able to make composeTestRunner dependent on the docker Task as there are cases where I don't want to image to be rebuilt.

I'm not 100% positive but I believe that there was another variation of the dependency issue due to the plugin giving flexibility to the user to define which Task they would like to execute for building the docker images as people typically use either sbt-docker or the sbt-native-packager for doing this. Since this isn't defined until the plugin is used by a project there was a problem with having a Task take a dependency on this Task as is not yet defined. Whereas when using a Command this was not an issue as the actual Task could be supplied at runtime.

If updates to sbt have made this possible or if there are good ways to rework the code so that Tasks can be used to handle these kind of scenarios I'd be all for switching over to use them instead as that is the preferred and recommended way to go.

As for your use cases, for 1 & 4 there is an multi-project example provided showing how you can have a separate docker compose file for each project along with an additional docker compose file in the root project that can contain the "all-up" configuration. Running dockerComposeUp from within the project scope will launch the particular compose instance for that specific project.

For example:
sbt "project sample1" dockerComposeUp
sbt "project sample2" dockerComposeUp

At Tapad we have many multi-project repositories using this model with separate docker compose files for each sub project and it has worked very well for us.

For use case 2: While not as nice as running "it:dockerComposeUp" or "test:dockerComposeUp", you could create an "integration" project and have a separate docker compose file defined within that project that specifies your integration specific setup.
sbt "project integration" dockerComposeUp

For use case 3: Even if the Commands were converted to Tasks I don't believe that you will be able to call the Tasks as steps within a larger Task as that is one of the issues that I ran into when they were Tasks in the first place.

I hope that this answer helps and let me know if you have any other questions or ways to work around the limitations I hit with the initial Task based implementation. Thanks again for the feedback!

[s-nel]

Thanks for explaining the rationale. It's perfectly sound, but I think some improvements to SBT may make implementing this in tasks less painful than it used to be. There are dynamic tasks now that allow you to conditionally depend on another task or decide which task to depend on at runtime. There is also support for sequential tasks for ordering tasks.

Thanks for explaining how each project can have its own docker config and there can be a separate file for root. I think that would solve my particular use cases satisfactorily.

When I mentioned calling docker compose tasks from other tasks I really meant depending on docker compose tasks from other tasks. That would be useful because currently it's quite difficult to integrate your plugin with other things (unless I just don't know how) without using commands. I think it's a smell that the plugin implements special commands for testing with docker. With tasks it's much easier, and you can attach to existing tasks (something that a given project could do based on its needs). Including specifying which tests to run with docker, which scope tests to run, extra configuration steps for tests, etc.

test in Test := Def.sequential(dockerComposeUp in Test, test in Test, dockerComposeDown in Test).value

[jeffreyolchovy]

@s-nel not sure if you have a better solution for this, but to depend on a docker compose command from a task you can do something like:

val myTask = taskKey[Unit]("just an example")

val myOtherTask = taskKey[Unit]("another example")

def runCommand(command: String, currentState: State): State = {
  sbt.complete.Parser.parse(command, currentState.combinedParser) match {
    case Right(cmd) => cmd()
    case Left(msg) => throw sys.error(s"Invalid input:\n$msg")
  }
}

val myProject = (project in file("my-project"))
  ...
  .settings(
    myTask := {
      println("invoking command..")
      val nextState = runCommand("dockerComposeUp", state.value)
      println("invoked command")
      println("invoking task..")
      myOtherTask.value
      println("invoked task")
    },
    myOtherTask := {
      println("hello world")
    }
  )
  .enablePlugins(DockerPlugin, DockerComposePlugin)

doesn't make any guarantees about sequencing though.

[kurtkopchik]

Closing this issue out. Please open a new issue if there are additional things to report.