New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Gradle 4.0 support? #12

Closed
blankdots opened this Issue Jun 27, 2017 · 6 comments

Comments

Projects
None yet
3 participants
@blankdots

blankdots commented Jun 27, 2017

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

@chrisgahlert

This comment has been minimized.

Owner

chrisgahlert commented Jun 27, 2017

Quick workaround:

Include this in your build.gradle:

allprojects { prj ->
    prj.tasks.withType(com.chrisgahlert.gradledcomposeplugin.tasks.AbstractDcomposeTask) { task ->
        task.dockerClassLoaderFactory.getDefaultInstance()
    }
}

I'll be releasing a new version soon... and thanks for reporting! ;)

@chrisgahlert

This comment has been minimized.

Owner

chrisgahlert commented Jul 4, 2017

Fixed in new version 0.9.1 available now.

@phauer

This comment has been minimized.

phauer commented Jul 4, 2017

Thank you for fixing this so fast!

@blankdots

This comment has been minimized.

blankdots commented Jul 4, 2017

@chrisgahlert Thank you!

Just a question regarding DcomposeCopyFileFromContainerTask as I noticed that with the new version i am having trouble copying the files (works in Gradle 3.5 with the new version of the plugin, files are copied). So does this look like a bug or I am doing something wrong (e.g. use Sync ?) or missing something (some changes in Gradle 4.0) ?

Error:

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':tests:copyReportFiles'.
> Docker command failed: Could not find the file /tmp/build/reports/tests in container dcompose_4164440d_test

The source:

task copyReportFiles(type: DcomposeCopyFileFromContainerTask) {
    service = dcompose.test
    containerPath = '/tmp/build/reports/tests'
    destinationDir = file("build/reports/")
    cleanDestinationDir = false
}

startTestContainer.finalizedBy copyReportFiles

If necessary I can provide the full Gradle file.

@chrisgahlert

This comment has been minimized.

Owner

chrisgahlert commented Jul 4, 2017

I don't think this is related to the plugin itself:

The DcomposeCopyFileFromContainerTask can copy files from containers - whether they are running or not (i.e. they might have never been started). The task only has a dependency on the create<Service>Container task.

For this reason I'm suspecting that you always copied the files from a container, where the startTestContainer task was previously executed causing the missing files to exist.

So in your example you would need to do the following:

  1. Add a dependency to the start task:
task copyReportFiles(type: DcomposeCopyFileFromContainerTask) {
    service = dcompose.test
    ...
    dependsOn startTestContainer // or more generic: "$service.projectPath:$service.startContainerTaskName"
}
  1. In order to wait for the container to finish it's task, I would recommend to add the following properties:
dcompose {
  test {
    // image,baseDir,command = ...
   
    waitForCommand = true // makes sure that the process will finish before moving to the copy task
    attachStdout = true // helpful for debugging: will be piped to System.out by default
    attachStderr = true // helpful for debugging: will be piped to System.err by default
  }
}
@blankdots

This comment has been minimized.

blankdots commented Jul 5, 2017

@chrisgahlert Thank you!!
Point 2 was already satisfied, also included point 1.

I was able to pinpoint the issue to how those tests reports were generated (or more precisely were not generated); I was not really happy with that env in the first place, so this gave me a good reason to change it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment