Improved Redeploy System

[MoonTM-GIT]

This PR aims to improve the redeploy system a bit. This deprecates the method described in #195.
This now requires a sh to be present at /bin/sh, in addition to an updated redeploy script to support all new features.

This is the redeploy script we now use to re-compile the Bot:

LOCATION="Location" #e.g /home/myUser/JavaBot

cd $LOCATION
rm -rf $LOCATION/redeploy/

git clone https://github.com/Java-Discord/JavaBot/ redeploy
cd redeploy

bash gradlew :shadow

if [ $? -eq 0 ]; then
        rm $LOCATION/JavaBot.jar
        mv $LOCATION/redeploy/build/libs/JavaBot-1.0.0-SNAPSHOT-all.jar $LOCATION/JavaBot.jar
else
        echo COMPILATION FAILED
        echo Did not replace file.
fi

As you can see this now only replaces the .jar if the compilation was successful. This is also used in the Bot to cancel the redeploy if the compilation did not succeed.

The location of this script has to be set in the Systems config. E.g. "redeployScriptLocation": "/home/myUser/JavaBot/redeploy.sh",

We still use a systemd service to run the bot, but we don't run this script before every start anymore, instead we only use this script for the /redeploy command. This allows us to restart the bot without waiting for it to compile again if we don't want that.

[danthe1st]

It might be worthy to use a variable in the redeploy script for specifying the bot directory (/home/$USR/JavaBot/).

Aside from that, it would be possible to build the JAR with GitHub Actions and let the bot query the GitHub API and download that.

The JAR file location (from a specific class) can also be obtained via reflection.

Furthermore, it is possible to update the bot purely in Java using ClassLoaders (requires a custom starter though).

Finally, shutting down jda.shutdown() (in combination with a listener on the shutdown event) could be used for properly shutting down.

[MoonTM-GIT]

It might be worthy to use a variable in the redeploy script for specifying the bot directory (/home/$USR/JavaBot/).

Yup, updated that.

Aside from that, it would be possible to build the JAR with GitHub Actions and let the bot query the GitHub API and download that.

I know, I also thought about that but I think I personally prefer to compile it myself.

Furthermore, it is possible to update the bot purely in Java using ClassLoaders (requires a custom starter though).

What would be the benefit of that? This script is easily executable if we don't have anything else running and it seems pretty simple.

[danthe1st]

What would be the benefit of that?

It would be platform independent, not require the script to be located at a specific path and doesn't require any external scripts at all.

This would make it easier to use in other environments.

[MoonTM-GIT]

It would be platform independent, not require the script to be located at a specific path and doesn't require any external scripts at all.

Yeah, but it also makes it harder to operate from outside the command which is quite important in my opinion.

[danthe1st]

We may want to move this to its own listener so that it is called when shutting down JDA completed.

[danthe1st]

It might be better to use the exit code of the script for checking whether it was successful or not.
For example, there could be errors other than the Gradle script failing (e.g. with git clone).

For failing with any error, set -e could be used in the script in order to abort the script as soon as any command fails.

[MoonTM-GIT]

Yup, will do that soon™️

[jasonlessenich]

Closed due to inactivity