Enable everyone to test servers with full plugins

[Fuglen]

By #79, it should be possible to tell which plugins each server uses by its gradle file, where it downloads all the plugins from our Nexus artifactory.

We might never enable everyone to install/remove plugins themselves, but if TFB admins only have to upload new plugins to Nexus, then users can use it in the gradle file.

Problem is: How do we make sure that no one can ever access the plugins that are downloaded from Nexus, while us staff do have access to the files?

• Possibly there could be some kind of authentication in our Docker image that decides our permissions to files in the local dev environment. For local environments we can setup Github Runners from our pipeline, so whenever they commit changes, the runner will run the servers on their machine for testing, but again how do we secure the plugins never get out?

• Could also be that we give access to anyone with full plugins to another environment like staging?

• Can we host a development environment ourselves and set permissions for .jar files only, so they can never be downloaded, edited, renamed to .zip or anything?

The problem with giving plugins to everyone locally is we have no control of our files on their computers. The problem with giving everyone access to a TFB Staging environment is... How is that even done with Git and all?

[Fuglen]

Since I opened this issue I have realized how great Github Codespaces is. It basically hosts our development environment on their amazing servers. It's free but with some hour limit every month, else its pretty cheap too.

To use this for everyone, we still need a way for them to never access some things:

• Plugins, servers or basically any .jar file.
• Secrets, environment variables, artifactory credentials etc.

[Fuglen]

Instead of developing remotely on our hardware, when they push commits to their branch, only a Github Runner runs a Dev environment where they can join the server (dev.theflyingbirds.net:randomport) and test. We just need to make sure everything is deleted again, so we keep resource usage down.

[lucas2kdk]

Possible solution could also be to convert our current infrastructure to Kubernetes, and spin up a new "pod" environment for the player with a max keep alive for X minutes. The environment could be created on commit.

[Fuglen]

Something like that would allow multiple users to test their branches at once, but we dont want it to run on Live hardware. But you are right, we want to spin up their environment on our own hardware where the only thing they can access is the Minecraft server itself.