7

I'm using gradle to automate docker publishing and tagging. I currently have the following set of tasks:

task dockerTagLatest(type: Exec) {
    description "Build a Docker image of the current version and tag it as 'latest'"
    dependsOn 'docker'
    group 'Publishing'

    commandLine(['docker', 'tag', dockerImageName, dockerImageLatest])
}

task dockerPush(type: Exec, overwrite: true) {
    description 'Push the Docker image of the current version to the internal Docker hub'
    group 'Publishing'
    mustRunAfter 'dockerTagLatest'

    commandLine 'docker', 'push', dockerImageName
}

task dockerPushLatestTag(type: Exec) {
    description "Push the 'latest' tag to the internal Docker hub"
    group 'Publishing'
    mustRunAfter 'dockerTagLatest'

    commandLine 'docker', 'push', dockerImageLatest
}

task dockerPublish() {
    description "Push the Docker image of the current version and the 'latest' tag to the internal Docker hub"
    dependsOn 'dockerTagLatest'
    dependsOn 'dockerPush'
    dependsOn 'dockerPushLatestTag'
    group 'Publishing'
}

Would it be better to have something like this?

task dockerPublish(type: Exec) {
    commandLine 'bash', '-e', '-c', """
        docker tag ...
        docker push ...
        docker push ...
    """
}

Obviously the second approach is not Windows friendly, but disregarding that for the moment, is it better to have a set of dependent Exec tasks, or to lump all of the command line commands into a single task? I've gotten feedback that the latter is more readable, but I think the first approach is more Gradle-like. Thoughts?

Michael Wu
  • 1,177
  • 1
  • 13
  • 34
  • Is there ever a scenario where you wouldn't want to run all of these tasks in that exact order? Could any of them be parallelized by future Gradle features? If the answer to either of these is "yes", then you may want to use separate tasks; otherwise one task is just fine – Eric Wendelin Nov 30 '15 at 23:10
  • That's a good point. While the `dockerPush` and `dockerPushLatest` tasks both depend on some `docker` task, those tasks themselves could potentially be parallelized. – Michael Wu Nov 30 '15 at 23:17
  • I'd start with a single task and observer the use cases. If it turns out that more specified functionality is needed, then I'd split the single tasks into smaller, and so on. – Opal Dec 01 '15 at 08:07
  • @EricWendelin I would vote your answer up if you put that into an answer :) – Renato Jul 21 '16 at 17:57
  • @Renato Alright :) http://stackoverflow.com/questions/34009417/multiple-bash-commands-in-single-gradle-exec-task-vs-multiple-gradle-exec-tasks/38511353#38511353 – Eric Wendelin Jul 21 '16 at 18:05
  • I realize this is old, but what's the -e do? – ernie Nov 23 '16 at 21:55
  • The e flag is a bash flag that causes bash to exit when a command fails. – Michael Wu Nov 23 '16 at 22:03

1 Answers1

3

Is there ever a scenario where you wouldn't want to run all of these tasks in that exact order? Could any of them be parallelized by future Gradle features?

If the answer to either of those is "yes", then you may want to use separate tasks; otherwise one task is just fine.

Eric Wendelin
  • 43,147
  • 9
  • 68
  • 92
  • As a side note: it is possible to [use another exec format as in this answer](https://stackoverflow.com/a/37520139/1087447), which avoids the Windows-unfriendly solution above. – Jazzschmidt May 13 '19 at 11:09