Support for no-color about sbt-docker-compose

[kurtkopchik]

Hi @hekaldama - I just released a 1.0.22-SNAPSHOT version of the plugin with a new suppressColorFormatting settingKey that can be defined in your build.sbt file.

// True to suppress all color formatting in the output from the plugin. This defaults to False.
suppressColorFormatting := true

resolvers += "Sonatype Snapshots" at "https://oss.sonatype.org/content/repositories/snapshots/"
addSbtPlugin("com.tapad" % "sbt-docker-compose" % "1.0.22-SNAPSHOT")

Let me know if this works for you and I'll get the changes merged into master for the next official release.

[hekaldama]

Thanks much. Will probably test early next week. Have a good one!

[hekaldama]

Was able to test and it is working as expected! TY!

I did notice that http://stackoverflow.com/a/31150651 mentions -no-colors can be passed into the command line now. Would it be possible to get that hooked up to your plugin?

[kurtkopchik]

Hi @hekaldama - Good suggestion! I pushed an update to the 1.0.22-SNAPSHOT release that defaults the suppressColorFormatting setting to respect the sbt.log.noformat system property which is what the -no-colors option sets.

This will allow you to run sbt -no-colors and have the plugin respect the setting without having to explicitly set suppressColorFormatting. Let me know if it works as expected for you.

[hekaldama]

Let me test, just got some errors from my build server because of this release. May be related to if a client supplies -no-colors && suppressColorFormatting := true then you get a failure like:

All tests passed.
Stopping and removing local Docker instance: 933942
Stopping 933942_thing_1 ... 
Stopping 933942_postgresDB_1 ... 
Removing 933942_thing_1 ... 
Removing 933942_postgresDB_1 ... 
Removing 933942_postgresDB_1 ... done
Going to remove 933942_thing_1, 933942_postgresDB_1
unknown flag: --format
See 'docker network ls --help'

I have been using the previos 1.0.22-SNAPSHOT on my localhost and that was working as expected.

[kurtkopchik]

This error looks unrelated to the latest change. What version of Docker are you running on the build server compared to your localhost?

The plugin attempts to remove any networks created by docker compose on shutdown and uses the following command to do so:
s"docker network ls --filter=name=${instanceName.replace('/', '_')}_$networkName --format={{.ID}}".!!.trim().nonEmpty

From the error message unknown flag: --format it looks like the version of docker on the build server is having an issue with this parameter.

If you type docker network ls --help on the build server does it support the --format param?

[hekaldama]

Ah! Build server is 1.12.6 and localhost is 17.04.0-ce. I was using sbt-docker-compose 1.0.20 in the past on the build server and it was working as expected. Is it terrible to request this no color option be backported to 1.0.20 :/.

Or possibly 1.0.22 could include logic to detect docker version and "do the right thing".

[hekaldama]

This will allow you to run sbt -no-colors and have the plugin respect the setting without having to explicitly set suppressColorFormatting. Let me know if it works as expected for you.

This has been tested to be working well with and with out -no-colors flag with docker version 17.04.0-ce.

[kurtkopchik]

I'm looking to see if I can make the docker network ls check without having to use the --format parameter which will make this logic more backwards compatible.

It appears that --format was introduced in v1.13.0-rc1

[hekaldama]

You can use -q. Just tested to be working on docker version 1.12.6.

[kurtkopchik]

Thanks @hekaldama - I've refreshed 1.0.22-SNAPSHOT to use -q instead of --format for backwards compatibility. Let me know if it works now!

[hekaldama]

Tested to be completing with proper exit code on jenkins which is running docker version 1.12.6! My last little nit pick is that sbt's -no-colors should translate to docker-compose's --no-color. Ref: docker/compose#1865

[kurtkopchik]

Hi @hekaldama, thanks for validating the change! Is there a case where you are seeing docker-compose outputting color codes via the plug-in when running from sbt with -no-colors set?

I can easily make the change to call docker-compose up with --no-color in this case but I wanted to make sure that I'm covering the use case you are hitting as I didn't see any color output myself when using the plugin from an sbt session with -no-colors set

[hekaldama]

I am seeing it when running dockerComposeTest on the last part when it is probably doing a docker-compose down.

[kurtkopchik]

Would you be able to paste the output snippet that you are seeing with color?

From the Docker documentation it does not appear that docker-compose stop/down have a parameter option that accepts --no-color. Only docker-compose up and docker-compose logs do and I don't believe that either of those should be printing any color output to the console from the plugin. (or at least the version of docker-compose that I'm using 1.11.2 does not appear to)

[hekaldama]

I think I am wrong, I think it is output from a rogue logger in my application. Thanks!

[kurtkopchik]

Thanks! I'll get this change into the next release and I'll update this issue once it's live.

[hekaldama]

Thanks. Its okay to use the snapshot for now, right?

[kurtkopchik]

Yes, you can use the SNAPSHOT release for now.

[kurtkopchik]

The fix for this issue is now included in an official release:

addSbtPlugin("com.tapad" % "sbt-docker-compose" % "1.0.22")

Thanks again for using the plugin!

[hekaldama]

Thanks for the responses and timely updates!

Should README.md mention the use of -no-colors as a way to disable as well?

[kurtkopchik]

Happy to help! I was going to add the -no-colors text to the README.md but I don't believe that all versions of sbt have that as an option and didn't want to cause any confusion with people who may be using older versions or not using sbt-extras.

[hekaldama]

Maybe just "If you are using sbt-extras, -no-colors will also enable this feature." Something like that so folks at least know it is there.

[kurtkopchik]

I'd be good with having that text added.

[hekaldama]

#62