Replies: 1 comment
-
That seems like a very difficult concept to implement. It also goes against a core principle of this image where all it can control is the setup of the working directory. After that it literally exec's off to the Java Minecraft process and gets out of the way. (Auto-pause is only slight exception to that paradigm.) Now if this is something that could have been observed from the spigot metadata, then that's something that could be in scope for the image setup. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hello,
I've realized that some issues related to plugins can happen, specifically this one:
When a plugin failed to load at server runtime, it becomes non deterministic, because the image runs fine, but something failed unexpectedly and wasn't caught by the expected CI of running this image.
Many things can fail, but a plugin is defined before server runtime, and the auto-update that SPIGET_RESOURCES has can be a source of unexpected issues and behaviors, I'm thinking that there should be an ENV variables that defines whether or not the image should accept plugins failing to load. And if we specifically said we don't accept it, it kills the container.
This could be detected through reading the stdout of the server process; or by using the rcon client and reading the /plugins output I guess?
I'm not opening an issue/enhancement just yet because I'm not convinced on wether the paradigm should be to be robust or error-free, but I guess having the ability to define it wouldn't hurt anyone.
Beta Was this translation helpful? Give feedback.
All reactions