Recent updates to linters revealed a number of potential code-quality
issues.
Most were related to the use of f-strings in loggers, which is
discouraged because the string interpolation is greedy (happens even if
that logging level is disabled) and because it makes the job of log
aggregators more difficult (unlikely to matter to us).
There was an instance of use of a "global" that was not intended to be
such. This was spotted by moving the core script-like functionality into
a function, which avoided adding names to the global namespace.
The script is also renamed to conform to python module-naming
conventions.
All warnings and errors are resolved, except the overly broad catching
of Exception, which is explicitly silenced.
Add a workflow for running the HelloWorld example in CI as a simple
sanity check on run-example functionality.
RunLmcpGen.py is renamed to run_lmcpgen.py, to be consistent with python
module naming guidelines.
run_lmcpgen.py is now wrapped by a shell script, `run-lmcpgen`. This
allows it to be used without requiring the user to manually activate the
python venv - just like run-example or anod. This also means that the
user is prompted to install infrastructure it needed.
Logging in run_lmcpgen.py is much improved: it is more verbose on info
(communicates what is being done to the user) and more accurate on
warning and critical (actually explain the problem correctly) and
provide remedial action (run anod devel-setup).
Logger config for run_lmcpgen.py and run-example.py is regularized
and refactored into uxas.util.logging - this eliminates redundant code
between the two files. e3 is still not required, but is used if
available.
A workflow has been added to GitHub Actions to test the invocation of
run-lmcpgen automatically.
In order to prove the ATBB, an assumption has to be made about the ARV service;
it should always output a non-empty list of eligible entities for an AutomationRequest. If the received AutomationRequest has a non-empty EntityList, nothing is changed. In the other case, it is replaced by the list of entities whose ARV service has Configuration and State available at the moment it processes the AutomationRequest.
RunLmcpGen.py no longer worked; the paths returned by the `uxas.paths`
python module were not correct; they were relative to the parent
directory of the OpenUxAS repo, not to the OpenUxAS repo itself.
Most likely, this occurred because of some change in the way the module
was installed in the python venv. To make this more robust, the paths
are now computed different: they look explicitly for the parent of the
.vpython directory itself.
Additionally, there was a possibility that the computation of the
`base_env` in RunLmcpGen.py would fail: the loop indexing requires that
the length of the array mod 2 be zero. This is now encoded explicitly.
