Add operation to get log from container

[lordofthejars]

Adds operation in Cube interface for getting log info from running container. With this devs will be able to get files from container in the test by using Cube interface.

Also adding anew property in configuration file so before container is stopped by Arquillian Cube logs will be copied in output local directory for manual inspection.

[lordofthejars]

In this issue we can do it two things:

• The first one by adding logContainerCmd method to DockerClientExecutor
• The second one by adding an attribute to arquillian.xml which you can set where to copy the log in local disk, so it can be inspected after execution.

To be more explicit, in arquillian.xml in every container definition I will provide next section:

tomcat:
  image: tutum/tomcat:7.0
  exposedPorts: [8089/tcp]
  await:
    strategy: polling
  beforeStop:
    - log:
        to: file path

[aslakknutsen]

@lordofthejars by DockerClient you mean CubeController?

[lordofthejars]

Sorry I mean by DockerClientExecutor. DockerClient already implements it.

[aslakknutsen]

I think a configuration option in arq.xml sounds like a good option.

I think we have two scenarios here;

• arquillian.xml; used to fetch complete logs for debug purpose
• programatically fetch log at a given time to e.g. assert on log state

[aslakknutsen]

@lordofthejars see #98 (comment)

[lordofthejars]

arquillian.xml; used to fetch complete logs for debug purpose

We need a way to set which container, all, a comma-separated value of which containers, so I decided to put them inside its own configuration.

programatically fetch log at a given time to e.g. assert on log state

This can be achieved by enriching test with DockerClient.

[aslakknutsen]

We need a way to set which container, all, a comma-separated value of which containers, so I decided to put them inside its own configuration.

I think this makes sense as a per container config. If you need to configure the same for multiple similar containers you can always use the extends option.

[lordofthejars]

Yes for this reason I suggested to add them in yaml format.

[aslakknutsen]

Agree on the general solution here, just not sure DockerClientExecutor is the right abstraction level to be exposing to the user.

[lordofthejars]

yes in fact to the user we are going to expose only DockerClient by enricher. But we need DockerclientExecutor to implement this method to be used internally.

[rbattenfeld]

Cool, I see you have already discussed this. Today, I saw that the docker API supports getting the logs. I can't remember yet from heart exactly if that is a kind of a stream. May you know that already.

[lordofthejars]

yes it is in binary docker raw type.