Giter VIP home page Giter VIP logo

gradle-dcompose-plugin's People

Contributors

chrisgahlert avatar henrik242 avatar sgdan avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar

gradle-dcompose-plugin's Issues

feat(healthcheck): Add helthcheck api for DefaultService

This is important for programmatic configuration of services in build-scripts.
When using

services.register("name") {
}

there should be an option to configure custom healthcheck, analogous to what following docker-compose.yml does:

  db:
    image: postgres:10
    ports:
      - "5432:5432"
    environment:
      POSTGRES_PASSWORD: tight5
    healthcheck:
      test: ["CMD", "pg_isready"]
      timeout: 5s
      retries: 3

Without this it is impossible to fully configure service programmatically.

Would like to apply multiple tags to the same image

It is pretty common when creating an image to give it more than one tag. For example tagging both with the version (possibly both with and without the patch level) and with latest. I'd like to do that for an image we describe in dcompose, but AFAICT each image is only given a single tag (based on the setting of the repository property).

Assuming I didn't miss something it would be nice to add a service property such as tags which would be a list of tags to apply when creating an image from the service.

Old volumes are reused

@chrisgahlert Is there a way to ensure that old volumes are not reused? I have tried setting the following without success:

preserveVolumes = false
forceRemoveImage = true

Unable to force deletion of an image

I try to remove my postgres image using removePostgresImage, but I get:

> Docker command failed: conflict: unable to remove repository reference "postgres:10-alpine" (must force) - container e9945b2f7f89 is using its referenced image 5232c1629c4d

Setting force = true isn't possible:

val removePostgresImage by tasks.getting(com.chrisgahlert.gradledcomposeplugin.tasks.image.DcomposeImageRemoveTask::class) {
                force = true
}
Line 155:                 force = true
                            ^ Val cannot be reassigned

Would like the ability to override default docker prefix.

I think that the only change needed is at line 44 in DcompseExtension. If it were to pass the closure {this.namePrefix} instead of simply {namePrefix} then any changes to that property (which is read/write) would be seen.

Not sure if this would cause other issues, but from what I can see in the code, I don't think it would. The unique prefix generated does prevent accidental collisions with other projects using the same names, but I don't think it is needed to do the up-to-date checks (again assume the artifact names are unique without the prefix).

Anyway, it would be a big help.

Start Container never ends

Hi! Congrats for this amazing plugin!

I'm trying to use it but I'm in troubles with the starting task. All works fine, but when I launch the startXXXXContainer and I have "waitForCommand=true" the task never ends. Is anyone experimenting the same thing ? any clue?

Thank you!

/var/run/docker.sock = localhost assumption is incorrect

Currently you are assuming that when the DOCKER_HOST is /var/run/docker.sock it means that all ports are exposed on localhost; this is incorrect.

When mounting /var/run/docker.sock into a docker container to allow the container to use the host's docker engine (aka Docker outside of Docker [DooD]) the host address of the exposed port becomes important. This scenario is used in CI quite a bit.

My current workaround is to use Docker in Docker (aka DinD) just for the integrationTest phase of our gradle build. This has drawbacks because DinD uses it's own layer cache inside the container; meaning it must re-pull all of our images for each integrationTest run.

I'm assuming just parsing the port information just as you do for DOCKER_HOST=tcp://blah:2375 would fix the issue (but I'm not quite sure).

Converting complete image ref (including tag) to lower case prevents use of mixed case tags.

While docker registry and repository names must be lower case, image tags are case sensitive. We have a need to publish tags that match existing images where upper case letters are used (see for example jboss/keycloak).

In the current code there are a few places that convert the image ref string to lower case after the tag is added, thus making it impossible for us to match the case as we would like.

I think the easiest way to address this will be to do the conversion to lower case in either the ImageRef.parse method or in the ImageRef constructor. At these points the tag is separated from the other parts and so it is possible to avoid changing its case. Later, when dealing with the entire reference string, that becomes much more difficult.

ConnectionClosedException with Docker for Mac 2.5.0.1

We get Docker command failed: org.apache.http.ConnectionClosedException: Premature end of chunk coded message body: closing chunk expected after upgrading Docker for Mac to 2.5.0.1. Downgrading to 2.4.0.0 fixes the problem.

org.gradle.api.GradleException: Could not evaluate onlyIf predicate for task ':fhh-web:stopApiContainer'.
        at org.gradle.api.internal.tasks.execution.SkipOnlyIfTaskExecuter.execute(SkipOnlyIfTaskExecuter.java:46)
        at org.gradle.api.internal.tasks.execution.CatchExceptionTaskExecuter.execute(CatchExceptionTaskExecuter.java:36)
        at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter$1.executeTask(EventFiringTaskExecuter.java:77)
        at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter$1.call(EventFiringTaskExecuter.java:55)
        at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter$1.call(EventFiringTaskExecuter.java:52)
        at org.gradle.internal.operations.DefaultBuildOperationRunner$CallableBuildOperationWorker.execute(DefaultBuildOperationRunner.java:200)
        at org.gradle.internal.operations.DefaultBuildOperationRunner$CallableBuildOperationWorker.execute(DefaultBuildOperationRunner.java:195)
        at org.gradle.internal.operations.DefaultBuildOperationRunner$3.execute(DefaultBuildOperationRunner.java:75)
        at org.gradle.internal.operations.DefaultBuildOperationRunner$3.execute(DefaultBuildOperationRunner.java:68)
        at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:153)
        at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:68)
        at org.gradle.internal.operations.DefaultBuildOperationRunner.call(DefaultBuildOperationRunner.java:62)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor.lambda$call$2(DefaultBuildOperationExecutor.java:76)
        at org.gradle.internal.operations.UnmanagedBuildOperationWrapper.callWithUnmanagedSupport(UnmanagedBuildOperationWrapper.java:54)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor.call(DefaultBuildOperationExecutor.java:76)
        at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter.execute(EventFiringTaskExecuter.java:52)
        at org.gradle.execution.plan.LocalTaskNodeExecutor.execute(LocalTaskNodeExecutor.java:41)
        at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$InvokeNodeExecutorsAction.execute(DefaultTaskExecutionGraph.java:372)
        at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$InvokeNodeExecutorsAction.execute(DefaultTaskExecutionGraph.java:359)
        at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$BuildOperationAwareExecutionAction.execute(DefaultTaskExecutionGraph.java:352)
        at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$BuildOperationAwareExecutionAction.execute(DefaultTaskExecutionGraph.java:338)
        at org.gradle.execution.plan.DefaultPlanExecutor$ExecutorWorker.lambda$run$0(DefaultPlanExecutor.java:127)
        at org.gradle.execution.plan.DefaultPlanExecutor$ExecutorWorker.execute(DefaultPlanExecutor.java:191)
        at org.gradle.execution.plan.DefaultPlanExecutor$ExecutorWorker.executeNextNode(DefaultPlanExecutor.java:182)
        at org.gradle.execution.plan.DefaultPlanExecutor$ExecutorWorker.run(DefaultPlanExecutor.java:124)
        at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:64)
        at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:48)
        at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:56)
Caused by: org.gradle.api.GradleException: Docker command failed: org.apache.http.ConnectionClosedException: Premature end of chunk coded message body: closing chunk expected
        at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
        at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:64)
        at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
        at com.chrisgahlert.gradledcomposeplugin.utils.DockerExecutor.runInDockerClasspath(DockerExecutor.groovy:34)
        at com.chrisgahlert.gradledcomposeplugin.utils.DockerExecutor$runInDockerClasspath$0.call(Unknown Source)
        at com.chrisgahlert.gradledcomposeplugin.tasks.container.DcomposeContainerStopTask.containerRunning(DcomposeContainerStopTask.groovy:62)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at com.chrisgahlert.gradledcomposeplugin.tasks.container.DcomposeContainerStopTask$_closure3.doCall(DcomposeContainerStopTask.groovy:45)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at org.gradle.api.specs.internal.ClosureSpec.isSatisfiedBy(ClosureSpec.java:33)
        at org.gradle.api.specs.AndSpec.isSatisfiedBy(AndSpec.java:50)
        at org.gradle.api.internal.tasks.execution.SkipOnlyIfTaskExecuter.execute(SkipOnlyIfTaskExecuter.java:44)
        ... 27 more
Caused by: javax.ws.rs.ProcessingException: org.apache.http.ConnectionClosedException: Premature end of chunk coded message body: closing chunk expected
        at org.glassfish.jersey.message.internal.EntityInputStream.isEmpty(EntityInputStream.java:194)
        at org.glassfish.jersey.message.internal.InboundMessageContext.hasEntity(InboundMessageContext.java:780)
        at com.github.dockerjava.jaxrs.filter.LoggingFilter.filter(LoggingFilter.java:249)
        at org.glassfish.jersey.client.ClientFilteringStages$ResponseFilterStage.apply(ClientFilteringStages.java:171)
        at org.glassfish.jersey.client.ClientFilteringStages$ResponseFilterStage.apply(ClientFilteringStages.java:159)
        at org.glassfish.jersey.process.internal.Stages.process(Stages.java:147)
        at org.glassfish.jersey.client.ClientRuntime.invoke(ClientRuntime.java:301)
        at org.glassfish.jersey.client.JerseyInvocation.lambda$invoke$0(JerseyInvocation.java:609)
        at org.glassfish.jersey.internal.Errors.process(Errors.java:292)
        at org.glassfish.jersey.internal.Errors.process(Errors.java:274)
        at org.glassfish.jersey.internal.Errors.process(Errors.java:205)
        at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:390)
        at org.glassfish.jersey.client.JerseyInvocation.invoke(JerseyInvocation.java:608)
        at com.github.dockerjava.jaxrs.JerseyDockerHttpClient.execute(JerseyDockerHttpClient.java:297)
        at com.github.dockerjava.core.DefaultInvocationBuilder.execute(DefaultInvocationBuilder.java:228)
        at com.github.dockerjava.core.DefaultInvocationBuilder.get(DefaultInvocationBuilder.java:202)
        at com.github.dockerjava.core.DefaultInvocationBuilder.get(DefaultInvocationBuilder.java:75)
        at com.github.dockerjava.core.exec.InspectContainerCmdExec.execute(InspectContainerCmdExec.java:31)
        at com.github.dockerjava.core.exec.InspectContainerCmdExec.execute(InspectContainerCmdExec.java:13)
        at com.github.dockerjava.core.exec.AbstrSyncDockerCmdExec.exec(AbstrSyncDockerCmdExec.java:21)
        at com.github.dockerjava.core.command.AbstrDockerCmd.exec(AbstrDockerCmd.java:35)
        at com.github.dockerjava.core.command.InspectContainerCmdImpl.exec(InspectContainerCmdImpl.java:52)
        at com.github.dockerjava.api.command.InspectContainerCmd$exec.call(Unknown Source)
        at com.github.dockerjava.api.command.InspectContainerCmd$exec.call(Unknown Source)
        at com.chrisgahlert.gradledcomposeplugin.tasks.container.DcomposeContainerStopTask$_containerRunning_closure4$_closure10.doCall(DcomposeContainerStopTask.groovy:64)
        at com.chrisgahlert.gradledcomposeplugin.tasks.container.DcomposeContainerStopTask$_containerRunning_closure4$_closure10.doCall(DcomposeContainerStopTask.groovy)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at com.chrisgahlert.gradledcomposeplugin.tasks.AbstractDcomposeTask.ignoreDockerExceptions(AbstractDcomposeTask.groovy:123)
        at jdk.internal.reflect.GeneratedMethodAccessor2011.invoke(Unknown Source)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at com.chrisgahlert.gradledcomposeplugin.tasks.AbstractDcomposeTask.ignoreDockerException(AbstractDcomposeTask.groovy:118)
        at jdk.internal.reflect.GeneratedMethodAccessor2012.invoke(Unknown Source)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at com.chrisgahlert.gradledcomposeplugin.tasks.container.DcomposeContainerStopTask$_containerRunning_closure4.doCall(DcomposeContainerStopTask.groovy:63)
        at com.chrisgahlert.gradledcomposeplugin.tasks.container.DcomposeContainerStopTask$_containerRunning_closure4.doCall(DcomposeContainerStopTask.groovy)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at com.chrisgahlert.gradledcomposeplugin.utils.DockerExecutor.runInDockerClasspath(DockerExecutor.groovy:32)
        ... 39 more
Caused by: org.apache.http.ConnectionClosedException: Premature end of chunk coded message body: closing chunk expected
        at org.apache.http.impl.io.ChunkedInputStream.getChunkSize(ChunkedInputStream.java:263)
        at org.apache.http.impl.io.ChunkedInputStream.nextChunk(ChunkedInputStream.java:222)
        at org.apache.http.impl.io.ChunkedInputStream.read(ChunkedInputStream.java:183)
        at org.apache.http.conn.EofSensorInputStream.read(EofSensorInputStream.java:135)
        at org.glassfish.jersey.message.internal.EntityInputStream.isEmpty(EntityInputStream.java:165)
        ... 79 more

Cannot load auth from ~/.docker/config.json

We have a private repository and have the auth info in the ~/.docker/config.json. This looks something like this:

{
    "auths": {
        "<registry hostname>": {
            "auth": "dGVzdC11aWQ6dGVzdC1wd2Q="
        }
    },
    "HttpHeaders": {
        "User-Agent": "Docker-Client/18.05.0-ce (darwin)"
    }
}

The problem is that the plugin is not reading this value but just sends empty auth values. To get it to work we had to

  1. read the auth value from the file
  2. extract username and password from the value
  3. set these in a registry section for the plugin

We get this error when the plugin tries to fetch an image:

Caused by: org.gradle.api.GradleException: Docker command failed: Could not build image: Get https://<repository hostname>/v2/x/y/manifests/10: unknown: Authentication is required
        at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
        at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
        at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
        at com.chrisgahlert.gradledcomposeplugin.tasks.AbstractDcomposeTask.runInDockerClasspath(AbstractDcomposeTask.groovy:179)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at com.chrisgahlert.gradledcomposeplugin.tasks.image.DcomposeImageBuildTask.buildImage(DcomposeImageBuildTask.groovy:93)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at org.gradle.internal.reflect.JavaMethod.invoke(JavaMethod.java:73)
        at org.gradle.api.internal.project.taskfactory.StandardTaskAction.doExecute(StandardTaskAction.java:46)
        at org.gradle.api.internal.project.taskfactory.StandardTaskAction.execute(StandardTaskAction.java:39)
        at org.gradle.api.internal.project.taskfactory.StandardTaskAction.execute(StandardTaskAction.java:26)
        at org.gradle.api.internal.AbstractTask$TaskActionWrapper.execute(AbstractTask.java:794)
        at org.gradle.api.internal.AbstractTask$TaskActionWrapper.execute(AbstractTask.java:761)
        at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter$1.run(ExecuteActionsTaskExecuter.java:131)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:317)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:309)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:185)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:97)
        at org.gradle.internal.operations.DelegatingBuildOperationExecutor.run(DelegatingBuildOperationExecutor.java:31)
        at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeAction(ExecuteActionsTaskExecuter.java:120)
        at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:99)
        ... 31 more
Caused by: com.github.dockerjava.api.exception.DockerClientException: Could not build image: Get https://<repository hostname>/v2/x/y/manifests/10: unknown: Authentication is required
        at com.github.dockerjava.core.command.BuildImageResultCallback.getImageId(BuildImageResultCallback.java:79)
        at com.github.dockerjava.core.command.BuildImageResultCallback.awaitImageId(BuildImageResultCallback.java:51)
        at com.github.dockerjava.core.command.BuildImageResultCallback$awaitImageId.call(Unknown Source)
        at com.github.dockerjava.core.command.BuildImageResultCallback$awaitImageId.call(Unknown Source)
        at com.chrisgahlert.gradledcomposeplugin.tasks.image.DcomposeImageBuildTask$_buildImage_closure3.doCall(DcomposeImageBuildTask.groovy:128)
        at com.chrisgahlert.gradledcomposeplugin.tasks.image.DcomposeImageBuildTask$_buildImage_closure3.doCall(DcomposeImageBuildTask.groovy)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at com.chrisgahlert.gradledcomposeplugin.tasks.AbstractDcomposeTask.runInDockerClasspath(AbstractDcomposeTask.groovy:177)
        ... 52 more

We have tried another plugin that uses the docker-java library and that one works. This seems to be a problem with how the library is used.

Generate docker-compose.yml usable by docker-compose

Hello Chris and kudos for the good work with the dcompose plugin!

Using the "createComposeFile" task, I'm able to create a docker-compose.yml file. However, the docker images referenced in docker-compose.yml files always have an hash string, for example "image: attxproject/uv-attx-dpus@sha256:d158441ae78993ce137f0ef82e6d41f504a0c66959f705b6aaa215d359ada2d9".

This makes it impossible to use the generated docker-compose.yml file with `docker-compose, as docker will evidently output the "ERROR: manifest unknown: manifest unknown" error, given that such image isn't either referenced in the local Docker registry or Docker Hub.

Is this a feature, or a bug? Please advise as it would be awesome to generate docker-compose.yml that could be used by docker-compose out-of-the-box.

Cheers,

João

Add "setter" for command property to ServiceReference

We have a use case where we create tasks which use a service that runs commands. To make this work we need to modify the command attribute of the service as part of the task definition. Currently we're using this:

compose {
    helm {
        image = 'vantiq/helm-kubectl:2.9.1'
        binds = [ volume("${project.clusterConfig}").bind('/root') ]
        waitForCommand = true
        attachStdout = true
    }
}

task helmVersion {
    doFirst {
        dcompose.findByName('helm').command = ['/usr/local/bin/helm', "version", '--short']
    }
    finalizedBy 'startHelmContainer'
}

task helmLs {
    doFirst {
        dcompose.findByName('helm').command = ['/usr/local/bin/helm', "ls"]
    }
    finalizedBy 'startHelmContainer'
}

However, this uses the deprecated findByName method to get the actual service. It would be better to use the service method, but currently we can't since the resulting ServiceReference doesn't have a setter for command.

ClassCastException with 0.16.4

I get a ClassCastException with 0.16.4. 0.16.3 does not have this problem. It's really weird, because I can't really see anything in the diff that should cause this.

:pale-pp-web:startSolrContainer (Thread[Execution worker for ':',5,main]) started.

FAILURE: Build failed with an exception.

* What went wrong:
ClassCastException: attempting to castjar:file:/Users/foo/.gradle/caches/jars-8/c36ad1861fd5cbd3b1b02659c2ba998c/jakarta.ws.rs-api-2.1.6.jar!/javax/ws/rs/client/ClientBuilder.class to jar:file:/Users/foo/.gradle/caches/modules-2/files-2.1/jakarta.ws.rs/jakarta.ws.rs-api/2.1.6/1dcb770bce80a490dff49729b99c7a60e9ecb122/jakarta.ws.rs-api-2.1.6.jar!/javax/ws/rs/client/ClientBuilder.class

* Try:
Run with --debug option to get more log output. Run with --scan to get full insights.

* Exception is:

* What went wrong:
ClassCastException: attempting to castjar:file:/Users/foo/.gradle/caches/jars-8/c36ad1861fd5cbd3b1b02659c2ba998c/jakarta.ws.rs-api-2.1.6.jar!/javax/ws/rs/client/ClientBuilder.class to jar:file:/Users/foo/.gradle/caches/modules-2/files-2.1/jakarta.ws.rs/jakarta.ws.rs-api/2.1.6/1dcb770bce80a490dff49729b99c7a60e9ecb122/jakarta.ws.rs-api-2.1.6.jar!/javax/ws/rs/client/ClientBuilder.class

* Try:
Run with --debug option to get more log output. Run with --scan to get full insights.

* Exception is:
java.lang.LinkageError: ClassCastException: attempting to castjar:file:/Users/foo/.gradle/caches/jars-8/c36ad1861fd5cbd3b1b02659c2ba998c/jakarta.ws.rs-api-2.1.6.jar!/javax/ws/rs/client/ClientBuilder.class to jar:file:/Users/foo/.gradle/caches/modules-2/files-2.1/jakarta.ws.rs/jakarta.ws.rs-api/2.1.6/1dcb770bce80a490dff49729b99c7a60e9ecb122/jakarta.ws.rs-api-2.1.6.jar!/javax/ws/rs/client/ClientBuilder.class
        at com.github.dockerjava.jaxrs.JerseyDockerHttpClient.<init>(JerseyDockerHttpClient.java:253)
        at com.github.dockerjava.jaxrs.JerseyDockerHttpClient.<init>(JerseyDockerHttpClient.java:45)
        at com.github.dockerjava.jaxrs.JerseyDockerHttpClient$Builder.build(JerseyDockerHttpClient.java:120)
        at com.github.dockerjava.jaxrs.JerseyDockerCmdExecFactory.init(JerseyDockerCmdExecFactory.java:44)
        at com.github.dockerjava.core.DockerClientImpl.withDockerCmdExecFactory(DockerClientImpl.java:242)
        at com.github.dockerjava.core.DockerClientBuilder.build(DockerClientBuilder.java:93)
        at com.github.dockerjava.core.DockerClientBuilder$build$1.call(Unknown Source)
        at com.chrisgahlert.gradledcomposeplugin.utils.DockerExecutor.getClient(DockerExecutor.groovy:69)

Docker v1.12 does not start

I'm trying to use your gradle plug-in and I have docker version 1.12. I get an error, "starting container with HostConfig was deprecated since v1.10 and removed in v1.12". I'm wondering if you are aware of this issue and if you have any plans on fixing it.

Support for Docker Compose file v3 ('createComposeFile' task)

Hi Chris!

I've been using your great Dcompose plugin to automate the building of Docker images, as well as the generation of docker-compose.yml files (y).

Regarding the latest, I have a use case for generating them in the latest "v3" format (https://docs.docker.com/compose/compose-file/), which is the deployment of service stacks to Docker Swarm Mode (https://docs.docker.com/engine/swarm/services/).

So, my question is: how can I use Dcompose to generate v3 docker-compose.yml files with the 'createComposeFile' task? Or is this a new feature? :-)

Cheers,

João

Create compose file from subprojects

Thank you for the awesome plugin, been using it quite frequently.
I have a question (maybe feature request) regarding creating a single compose file from multiple subprojects. As it is easier to exemplify here it goes:
I have this project structure:

.
├── subproject1
│   ├── build.gradle
│   ├── Dockerfile
│   └── README.md
├── build.gradle
├── common.gradle
├── subproject2
│   ├── build.gradle
│   ├── Dockerfile
│   ├── nginx.conf
│   ├── README.md
│   └── web
│       ├── index.html
│       └── style.css
├── README.md
└── settings.gradle

In each of the subprojects as well as the root project, in build.gradle file there is something like (number of dockerfiles might vary):

dcompose {
    createComposeFile.useTags = true
    version = '3' // default - also supports '2'
    networks {
        prodEnv
    }
    registry ("$registryURL") {
    // Needs no user/pass
        }
    subproject1 {
        baseDir = file('.')
        repository = "${imageRepo}:${imageRepoPort}/image-name:latest"
        portBindings = ['8080:8080']
        binds = ['/data/subproject1:/data/subproject1']
        networks = [prodEnv]
    }
}

Now when I do gradle CreateComposeFile it creates a compose file for each subproject and that is an expected behaviour (because there is a need to run those services separately), but at the same time i want a single docker-compose file which includes all subprojects composefiles.

Is there an way to do that, might have missed something in the documentation? Or I might miss something to do this easier, or if this could be a feature it would be much appreciated.

Group names for service tasks display as a closure reference

When I do gradle tasks I get a bunch of task entries like this:

Com.chrisgahlert.gradledcomposeplugin.DcomposePlugin$_updateTaskGroups_closure4$_closure12@2c80b0c8 tasks
---------------------------------------------------------------------------------------------------------
removeMongodbContainer

I think this is due to the task group property being assigned a cluster and not its result. I'm running Gradle 3.1.

Can't run multiple "waitForCommand" services in single gradle exection.

When we try to create multiple tasks, each of which will cause a "waitForCommand" service to execution we get the following exception:

Caused by: org.gradle.api.GradleException: Docker command failed: There's an extension registered with name 'exitCode'. You should not reassign it via a property setter.
        at com.chrisgahlert.gradledcomposeplugin.utils.DockerExecutor.runInDockerClasspath(DockerExecutor.groovy:34)
        at com.chrisgahlert.gradledcomposeplugin.utils.DockerExecutor$runInDockerClasspath$0.call(Unknown Source)
        at com.chrisgahlert.gradledcomposeplugin.tasks.container.DcomposeContainerStartTask.startContainer(DcomposeContainerStartTask.groovy:89)
        at com.chrisgahlert.gradledcomposeplugin.tasks.container.DcomposeContainerStartTask$startContainer.call(Unknown Source)

I think this is due to the following line of code at line 109 in DcomposeContainerStartTask:

extensions.exitCode = service.exitCode

Given that the exit code is stored in the service it doesn't seem necessary to also store it as an "extension" object as well, but I'm obviously not sure what use case is being addressed here.

Gradle 4.0 support?

Been trying to run the same projects I have set up dcompose in with Gradle 4.0 and the following error keeps popping up:

FAILURE: Build failed with an exception.

* What went wrong:
Docker command failed: An attempt was made to execute build operations inside of a resource lock transform.  Aborting to avoid a deadlock.
> An attempt was made to execute build operations inside of a resource lock transform.  Aborting to avoid a deadlock.

Everything works fine in Gradle 3.5

Add support for "top level" volumes

Unless I'm missing something (which I easily could be), I don't see a way to create top level volumes (e.g. those created by the docker volume create command). Is that something you are considering adding?

Intermittent "Container id not available for service database - has it been started?"

Intermittent "Container id not available for service database - has it been started?"
Gradle: 7.1.1
dcompose: 0.17.2

"database" service configuration:

configure<DcomposeExtension> {
	System.getenv("BUILD_NAME")
		?.let { DcomposeUtils.sha1Hash(it).substring(0, 8) }
		?.run {
			namePrefix = "${namePrefix}_$this"
		}
	networks.clear()

	services.register("database") {
		image = "postgres:11-alpine"
		env = listOf(
			"POSTGRES_USER=Test",
			"POSTGRES_PASSWORD=Test",
			"POSTGRES_DB=Test"
		)
		portBindings = listOf("5432")
		networkMode = "bridge"
		waitForHealthcheck = true
		healthcheckInterval = 500
		healthcheckTimeout = 3500
		healthcheckRetries = 10
		healthcheckStartPeriod = 10000
		healthcheckTest = listOf("CMD-SHELL", "pg_isready -U \$POSTGRES_USER -d \$POSTGRES_DB || exit 1")
	}
	tasks.named<Test>("testI") {
		dependsOn("startDatabaseContainer")
		doFirst {
			systemProperty("DB_HOST", service("database").dockerHost)
			systemProperty(
				"DB_PORT", service("database")
					.findHostPort(mapOf("hostIp" to "0.0.0.0"), 5432)
			)
		}
		finalizedBy("removeDatabaseContainer")
	}
}

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.