You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Due to our testsetup (arquillian, junit, multi-threaded surefire) we create one (subclass of) DockerCube, representing our testcontainer, which handles a number of testclasses by repeatedly creating, starting, stopping, destroying that testcontainer. However, since #957 / #958 calling create on a destroyed DockerCube does nothing due to the state check on https://github.com/arquillian/arquillian-cube/pull/958/files#diff-68554bf6fbadc1793c97b89f358bc69fR101
I can't think of a good reason why a destroyed container can't be recreated. Is it possible to modify the state-check so it also accepts DESTROYED when calling create() ?
If I overwrite the state value in our DockerCube subclass to set it to BEFORE_CREATE if it is DESTROYED our tests run as expected.
In essence, something like this happens:
DockerCube cube = new DockerCube();
Calling create() on a DESTROYED DockerCube recreates the container so that we can start() it once again.
Current Behaviour
Calling create() on a DESTROYED DockerCube does nothing, causing the subsequent start() to result in a "container not found".
Steps To Reproduce
I have no easily reproducible steps because the setup is complicated, meaning it would take time, and I think the problem is easily describable.
Additional Information
As this is more of an enhancement request I don't think any additional information is necessary, but if you would like more information please ask me 😃
The text was updated successfully, but these errors were encountered:
I am facing the same issue.
Before #957 I was able to have multiple @RunWith(Arquillian.class) tests on the same project. It is no more the case because after the first case is done, the swarm container is DESTROYED and the property state is defined as DESTROYED in DockerCube instance.
At the next Test, when cube want to create a new swarm container the condition at the beginning of the method create() is unmet (because state is defined to DESTROYED by the previous test) and the container is no more created :(
public void create() throws CubeControlException {
if (state != State.BEFORE_CREATE) {
return;
}
state is defined to State.BEFORE_CREATE only when creating a new DockerCube.
So I guess DockerCube must be recreated between each test.
Issue Overview
Due to our testsetup (arquillian, junit, multi-threaded surefire) we create one (subclass of) DockerCube, representing our testcontainer, which handles a number of testclasses by repeatedly creating, starting, stopping, destroying that testcontainer. However, since #957 / #958 calling create on a destroyed DockerCube does nothing due to the state check on
https://github.com/arquillian/arquillian-cube/pull/958/files#diff-68554bf6fbadc1793c97b89f358bc69fR101
I can't think of a good reason why a destroyed container can't be recreated. Is it possible to modify the state-check so it also accepts DESTROYED when calling create() ?
If I overwrite the state value in our DockerCube subclass to set it to BEFORE_CREATE if it is DESTROYED our tests run as expected.
In essence, something like this happens:
DockerCube cube = new DockerCube();
cube.create(); // testclass 1
cube.start();
...
cube.stop();
cube.destroy();
cube.create(); // testclass 2
cube.start();
...
Expected Behaviour
Calling create() on a DESTROYED DockerCube recreates the container so that we can start() it once again.
Current Behaviour
Calling create() on a DESTROYED DockerCube does nothing, causing the subsequent start() to result in a "container not found".
Steps To Reproduce
I have no easily reproducible steps because the setup is complicated, meaning it would take time, and I think the problem is easily describable.
Additional Information
As this is more of an enhancement request I don't think any additional information is necessary, but if you would like more information please ask me 😃
The text was updated successfully, but these errors were encountered: