Pull is wrongfully attempted for locally-built image

[ches]

Hi @kurtkopchik,

This is the issue/question I referred to in #80:

I have a single-module sbt project and a docker-compose.yml that runs multiple service containers, one of which being the application image for the project built by sbt-native-packager via sbt-docker-compose. If I remove the application service—leaving only the remotely-published images—and set composeNoBuild := true then I can run the Compose environment through sbt as expected, so my system setup basically works. But with the application service included, its image gets locally built but then the plugin tries to pull it from remote registry instead of recognizing it as local.

Here's the relevant output on dockerComposeUp when I (successfully) run the basic-native-packager example which is closest to my usage:

[info] Built image basic:1.0.0
Creating Local Docker Compose Environment.
Reading Compose File: /Users/cmartin/src/sbt-docker-compose/examples/basic-native-packager/docker/docker-compose.yml
Created Compose File with Processed Custom Tags: /var/folders/r1/yj9gp8sx2znb08j427kgyl5d8c3f9w/T/compose-updated1542783405310045140.yml
Pulling Docker images except for locally built images and images defined as <skipPull> or <localBuild>.
Skipping Pull of image: basic:1.0.0

Looks good, built the image and then sbt-docker-compose skipped trying to pull it. But when running for my project, I see this:

[info] Built image DockerAlias(Some(mycompanyregistry.org/my-team),None,my-app,Some(latest))
Creating Local Docker Compose Environment.
Reading Compose File: /Users/cmartin/src/mycompany/my-team/my-app/docker-compose.yml
Created Compose File with Processed Custom Tags: /var/folders/r1/yj9gp8sx2znb08j427kgyl5d8c3f9w/T/compose-updated786481022455347392.yml
Pulling Docker images except for locally built images and images defined as <skipPull> or <localBuild>.
Pulling repository mycompanyregistry.org/my-team/my-app
invalid character '<' looking for beginning of value
2.1.14: Pulling from library/cassandra
Digest: sha256:c1ec441d7b4e04ede4e645bfc34ea4069fc90904676998240e4c135911fdf11f
Status: Image is up to date for cassandra:2.1.14
0.9.0.1: Pulling from ches/kafka
012a7829fd3f: Already exists
41158247dd50: Already exists
916b974d99af: Already exists
a3ed95caeb02: Already exists
a3ed95caeb02: Already exists
a3ed95caeb02: Already exists
a3ed95caeb02: Already exists
b33a83f5a279: Already exists
c7572144309b: Already exists
711f8578e1f8: Already exists
15a61b3f48c1: Already exists
77fe76114497: Already exists
f67e1e2c91c8: Already exists
714116a3e57a: Already exists
18511de21194: Already exists
a5d90c80930c: Already exists
b432d205d520: Already exists
Digest: sha256:de7ed1b61c38441be44878a0b6ad6f090a590cd9afbc7b14bd5c04f84c4d1399
Status: Image is up to date for ches/kafka:0.9.0.1
3.4: Pulling from library/zookeeper
Digest: sha256:6308fff92245ff7232e90046976d2c17ffb363ae88c0d6208866ae0ab5a4b886
Status: Image is up to date for zookeeper:3.4
Creating network "634132_default" with the default driver
Creating volume "634132_cassandra-data" with default driver
Creating volume "634132_kafka-logs" with default driver
Creating volume "634132_kafka-data" with default driver
Pulling my-app (mycompanyregistry.org/my-team/my-app:latest)...
Pulling repository mycompanyregistry.org/my-team/my-app
invalid character '<' looking for beginning of value
No stopped containers
634132_default
Error starting Docker Compose instance. Shutting down containers...

So clearly my app image gets built, but then we try to pull it, which shouldn't happen.

(The invalid character '<' looking for beginning of value messages come directly from the response from our registry—a poor error message, but it's the result of trying to pull a nonexistent image).

Here are the minimized bits of my relevant configs:

/* NATIVE PACKAGER */
// We don't use Docker images for production deployment yet, they're for testing/CI
enablePlugins(JavaServerAppPackaging, DockerPlugin)

// Make sure we don't `docker:publish` this to the public Docker Hub
dockerRepository := Some("mycompanyregistry.org/my-team")
packageName in Docker := "my-app"

version in Docker := { if (isSnapshot.value) "latest" else version.value }

/* SBT-DOCKER-COMPOSE */
enablePlugins(DockerComposePlugin)
dockerImageCreationTask := (publishLocal in Docker).value

version: '3'

services:

  # Our app is not published to remote registry at this time. Build locally with:
  #    sbt docker:publishLocal
  # Or it will be built automatically for functional test runs.
  my-app:
    image: mycompanyregistry.org/my-team/my-app:latest
    depends_on:
      - kafka
      - cassandra

  cassandra:
    image: cassandra:2.1.14
    ports:
      - '9042:9042'  # Thrift
      - '9160:9160'  # CQL
    volumes:
      - cassandra-data:/var/lib/cassandra
    environment:
      # Avoid having to specify host if you want to `docker-compose run cassandra cqlsh`
      CQLSH_HOST: cassandra

  kafka:
    image: ches/kafka:0.9.0.1
    ports:
      - '9092:9092'  # Broker
      - '7203:7203'  # JMX
    depends_on:
      - zookeeper
    volumes:
      - kafka-data:/data
      - kafka-logs:/logs
    environment:
      KAFKA_ADVERTISED_HOST_NAME: localhost
      ZOOKEEPER_IP: zookeeper

  zookeeper:
    image: zookeeper:3.4
    restart: unless-stopped
    ports:
      - '2181:2181'

volumes:
  cassandra-data:
  kafka-data:
  kafka-logs:

(Specific local ports were bound for local development, this will be changed for sbt builds once it's working, don't worry 😄 ).

I'm starting to look over the code for why this might be happening, and I can produce an actual reproduction project if you like (or send one as a PR for the examples directory), but I wanted to make sure I'm not simply misunderstanding something about intended usage. This almost works; it should work, right?

[kurtkopchik]

Hi @ches, thanks for the detailed write-up!

There are two settings you should be aware of:

1. There is a skipPull argument you can pass to dockerComposeUp that will result in only local images being used for all images instead of pulling from the registry. This also is useful for the scenario you describe in Consider Docker labels in lieu of "custom tags" #80 where you are on an airplane, or do not have an internet connection, and you do not want to attempt to connect to the docker registry when starting the compose instance.

dockerComposeUp skipPull

2. To determine which docker compose service is being built by the current sbt project the plugin attempts to find a docker-compose.yml service name that matches the sbt project name. If it finds a match then it considers that image to be built by the current project and it will not attempt to pull it from the registry. Looking at your project above I'm guessing that your sbt project name is different than my-app therefore the plugin does not know that it should bypass the pulling of this image.

The composeServiceName setting can be used to explicitly define what service name in the docker-compose.yml file should be mapped to the project as the one being built locally if the name differs from that of the sbt project.
composeServiceName := // Specify the name of the service in the Docker Compose file being tested. This setting prevents the service image from being pull down from the Docker Registry. It defaults to the sbt Project name.

Let me know if that fixes the issue you are seeing. If not, a reproduction of the project would be very helpful as what you are attempting to do should work.

[ches]

The composeServiceName setting can be used to explicitly define what service name in the docker-compose.yml file should be mapped to the project as the one being built locally if the name differs from that of the sbt project.

Ahhh this is the ticket! I completely overlooked the existence of that setting and hadn't come across the logic yet, my apologies. Indeed the Compose service name and Docker image name are simplified from the project name so this was precisely the issue. A second catch was that sbt/sbt-native-packager#947 was causing packageName in Docker to not result in the expected image name when built, upgrading to the latest milestone cleared that up. Now everything is clicking.

And you're right that dockerComposeUp skipPull should address the "airplane" scenario, I'd misunderstood it on first reading.

Thanks again for your quick and helpful responses.