Dump system info and processing status to file

[godsic]

At the moment system properties and processing status is not exposed to client software. Some go as far as parsing the web gui page to figure out this information. Lets make thier life easier and dump potentially useful information to json file, which can also be accessed over web. This PR addresses #108. gitpython module is now recommended.

[godsic]

@dubrsl @alexeysirenko @redradist Please provide your comments guys.

[redradist]

@godsic LGTM

[dubrsl]

Sorry, but add dependency to SCM git in application is bad idea.

1. Someone may be using a different SCM (Source Control Management). Like mercurial, svn or smth. proprietar.
2. By default, BuildKit doesn't keep the .git directory when using Git contexts. https://docs.docker.com/build/building/context/#keep-git-directory The .git folder can be deleted to reduce image size or disk space usage.

I suggest simply exporting the manually set value. The value store in a static configuration file, which will be updated when a new release is released.

[dubrsl]

Might make sense adding a general status. By checking which you can see whether the receiver is ready or not.

[godsic]

Fair enough, added daq_ok.

[godsic]

@dubrsl Thanks for your feedback. Unfortunately, I cannot follow the first point, since the project opted for git as SCM. If you are talking about somebody who might have cloned it and turned into another SCM (e.g., Mercurial), then I don't think we should support that case. Regarding second one, I see your point for sure. Nevertheless I am not a fan of such manual steps, especially, given the fact that some of us run krakensdr_doa not aligned with releases and knowing the actual commit hash is beneficial for debugging purposes.

[dubrsl]

@dubrsl Thanks for your feedback. Unfortunately, I cannot follow the first point, since the project opted for git as SCM. If you are talking about somebody who might have cloned it and turned into another SCM (e.g., Mercurial), then I don't think we should support that case.

Ok.

Regarding second one, I see your point for sure. Nevertheless I am not a fan of such manual steps, especially, given the fact that some of us run krakensdr_doa not aligned with releases and knowing the actual commit hash is beneficial for debugging purposes.

I'm sure no one installs manually. And uses scripts https://github.com/krakenrf/krakensdr_docs/tree/main/install_scripts or Dockerfile. Therefore, I suggest setting the version and git hash in _ui/_web_interface/variables.py using this script. And remove the dependency on git.
Or expect, that the git folder may not exist.

[godsic]

@dubrsl I now handle cases of missing gitpython module or .git folder.

[dubrsl]

Using built metadata with version should be used via "+" and dot separated identifiers.
https://semver.org/#spec-item-10
Propose
{SOFTWARE_VERSION}+git.{SOFTWARE_GIT_HASH}

[godsic]

@dubrsl Fixed according to your suggestion, but with short hash instead of full one.

[dubrsl]

More thoughts. Is it possible to run a custom script(s) and include the result(s) it provides in the status?
In this way we can add various information on sensors (CPU temperature, battery charge when using UPS), system status (LA, RAM usage, free disk space) etc..

[godsic]

More thoughts. Is it possible to run a custom script(s) and include the result(s) it provides in the status? In this way we can add various information on sensors (CPU temperature, battery charge when using UPS), system status (LA, RAM usage, free disk space) etc..

Most of those metrics can be retrieved using python built-in or 3rd party modules. I am happy to add those in followup.