-
-
Notifications
You must be signed in to change notification settings - Fork 50
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
"Cannot remove extraneous deployment marker file" leads to strange behavior #17
Comments
lmsurpre
added a commit
to lmsurpre/testcontainers-keycloak
that referenced
this issue
Apr 15, 2021
By mounting its parent directory instead of just the specific file, then marking it writeable for others. I also upgraded it to Keycloak 12.0.4, but I can easilly revert that if you want.
Thanks @lmsurpre for reporting, I'll have a look into this. @thomasdarimont can you pls also have a look at it, as this extension was contributed by you. Thanks. |
lmsurpre
added a commit
to lmsurpre/testcontainers-keycloak
that referenced
this issue
Apr 20, 2021
Apparently mounting a temporary directory to the same location as the target classes was not working on Fedora with Podman. The new approach is to add the `.dodeploy` file directly to the extensionClassFolder which already has a volume mount at this location.
lmsurpre
added a commit
to lmsurpre/testcontainers-keycloak
that referenced
this issue
Apr 20, 2021
Apparently mounting a temporary directory to the same location as the target classes was not working on Fedora with Podman. The new approach is to add the `.dodeploy` file directly to the extensionClassFolder which already has a volume mount at this location.
thomasdarimont
added a commit
to thomasdarimont/testcontainers-keycloak
that referenced
this issue
Apr 20, 2021
lmsurpre
added a commit
to lmsurpre/testcontainers-keycloak
that referenced
this issue
Apr 20, 2021
Copy the deploymentTriggerFile to the container instead of setting up a bindMount for it.
lmsurpre
added a commit
to lmsurpre/testcontainers-keycloak
that referenced
this issue
Apr 20, 2021
Copy the deploymentTriggerFile to the container instead of setting up a bindMount for it.
thomasdarimont
added a commit
to thomasdarimont/testcontainers-keycloak
that referenced
this issue
Apr 20, 2021
lmsurpre
added a commit
to lmsurpre/testcontainers-keycloak
that referenced
this issue
Apr 20, 2021
Copy the deploymentTriggerFile to the container instead of setting up a bindMount for it.
thomasdarimont
added a commit
to thomasdarimont/testcontainers-keycloak
that referenced
this issue
Apr 20, 2021
We now trigger deployment of exploded extensions folders during container start by copying a dynamically generated ".dodeploy" file. Previously we mounted an external ".dodeploy" file into the container which did not work on some operating systems (OSX) when container reuse was used. Fixes dasniko#17
thomasdarimont
added a commit
to thomasdarimont/testcontainers-keycloak
that referenced
this issue
Apr 20, 2021
We now trigger deployment of exploded extensions folders during container start by copying a dynamically generated ".dodeploy" file. Previously we mounted an external ".dodeploy" file into the container which did not work on some operating systems (OSX) when container reuse was used. Fixes dasniko#17
thomasdarimont
added a commit
to thomasdarimont/testcontainers-keycloak
that referenced
this issue
Apr 20, 2021
We now trigger deployment of exploded extensions folders during container start by copying a dynamically generated ".dodeploy" file. Previously we mounted an external ".dodeploy" file into the container which did not work on some operating systems (OSX) when container reuse was used. Fixes dasniko#17
thomasdarimont
added a commit
to thomasdarimont/testcontainers-keycloak
that referenced
this issue
Apr 20, 2021
We now trigger deployment of exploded extensions folders during container start by copying a dynamically generated ".dodeploy" file. Previously we mounted an external ".dodeploy" file into the container which did not work on some operating systems (OSX) when container reuse was used. Fixes dasniko#17 (cherry picked from commit 1e95cb6)
@dasniko I think I have a sound fix for this issue now, would you mind having a look? :) |
thomasdarimont
added a commit
to thomasdarimont/testcontainers-keycloak
that referenced
this issue
Apr 20, 2021
We now trigger deployment of exploded extensions folders during container start by copying a dynamically generated ".dodeploy" file. Previously we mounted an external ".dodeploy" file into the container which did not work on some operating systems (OSX) when container reuse was used. Fixes dasniko#17 (cherry picked from commit 1e95cb6)
Thanks @thomasdarimont and @lmsurpre for figuring out and having a solution which works on all tested platforms. |
dasniko
pushed a commit
that referenced
this issue
Apr 23, 2021
We now trigger deployment of exploded extensions folders during container start by copying a dynamically generated ".dodeploy" file. Previously we mounted an external ".dodeploy" file into the container which did not work on some operating systems (OSX) when container reuse was used. Fixes #17 (cherry picked from commit 1e95cb6)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I enabled the experimental testcontainers "withReuse" option and, after my tests completed, I went to check out the still-running container.
What I found is general flakiness. For example, after login, it would say the admin console page doesn't exist / couldn't be found. Then, after a refresh, it would work pretty well. Occasionally I would see an intermittent error on the UI, but it was still usage.
I dug into the logs to look for errors and I found the following output was repeated over and over again, basically drowning everything else out:
I'm not sure if the constantly reloading is a feature or a bug, but when I dug in I found that the reason it cannot delete the deployment marker file is that this file is a direct mount point.
When I fixed it locally, by mounting a directory instead of just the file, the container started to behave perfectly...no more wonkiness.
The text was updated successfully, but these errors were encountered: