feat: Adding additional logging and configuration

[CEbbinghaus]

To aid in troubleshooting bug reports more information will be required. To this end the log crate is being replaced with trace which is a lot more powerful. A toml configuration file is also added to allow configuration of the backend, including the level the logs should be written as.

[jfreuden]

It seems that moving the version file angers the backend compilation in the CI/CD github pipeline. Got this from lines 494-504 of the build log

     Compiling backend v0.0.0 (/backend)
  error: couldn't read src/../version: No such file or directory (os error 2)
   --> src/env.rs:5:43
    |
  5 | pub const PACKAGE_VERSION: &'static str = include_str!("../version");
    |                                           ^^^^^^^^^^^^^^^^^^^^^^^^^^
    |
    = note: this error originates in the macro `include_str` (in Nightly builds, run with -Z macro-backtrace for more info)
  
  error: could not compile `backend` (bin "backend") due to previous error
  mv: cannot stat 'target/docker/backend': No such file or directory

I confirmed that it didn't do this previously here

[CEbbinghaus]

@jfreuden REALLY good catch. Wow I cannot believe the action passed even though it threw. I investigated it and it looks like Docker is once again the problem, Second being the fact that the Decky build tool requires the docker command to be run in a specific way. I think in future I will want to expand the tool to allow arbitrary binds (so I can just mount the file in the right location) but for the moment it looks like I will have to once again swap them around so the "original" is in the backend folder...

I really wish that docker let you copy a file from outside its directory :/

[jfreuden]

I saw that you fixed the version error as well as got rid of the warnings. Did you ever figure out how to ensure the Action sees a compile error of backend as an unrecoverable failure?

[CEbbinghaus]

Not yet. the docker run command succeeds even if the process fails. I need to find a way for the docker container to exit with the same status code as the process did.

[jfreuden]

The build has entrypoint.sh as the... entrypoint... and in there it makes a new shell with bash which runs build-docker.sh and in that script the cargo build --profile docker line is run, but doesn't exit when it fails.
Should be able to either do a simple cargo build --profile docker || exit 1 for the hacky version or

cargo build --profile docker
BUILD_EXIT=$?
# ... rest of script then last line ...
exit $BUILD_EXIT

I'm not sure whether something similar needs to be done on the entrypoint.sh script. Maybe, maybe not. I'm gonna see if I can't test this on my fork and get you the answer in a couple of hours

[jfreuden]

Well the good news is that my solution does make docker now see failures but the decky plugin build still doesn't care and it barges right in to the frontend build. oh well. I'm pretty sure I have a project lying around somewhere that had a similar issue a long time ago. I'll keep looking for a solution as well but I'm wondering if it's a decky problem we can't solve here...

[CEbbinghaus]

Wonderful, Thank you so much for helping fix that <3

[jfreuden]

Wonderful, Thank you so much for helping fix that <3

I put a PR pointing to this branch, so that as you keep working on this PR the actions will only take a CLI update in order to show accurate runner statuses. I can also cherry pick it to point wherever, it doesn't really matter where it goes 😄

[CEbbinghaus]

Lets hope I didn't miss anything :3