Add workflows for codeql and component testing

[heinpa]

Execute Java and Python component tests whenever a new PR is made to the master branch. This should check that code changes do not change the intended behaviour or that tests were updated to reflect the new functionality. These tests would also reveal if component updates depend on external updates to the Qanary repository (like commons). They would fail if some components depend on changes to Qanary, that have not yet made it into the main branch. A GitHub action ensures that the tests are executed at least once before changes are merged into the main branch.

Execute CodeQL for every new PR and push to master branch.

[github-advanced-security[bot]]

This pull request sets up GitHub code scanning for this repository. Once the scans have completed and the checks have passed, the analysis results for this pull request branch will appear on this overview. Once you merge this pull request, the 'Security' tab will show more code scanning analysis results (for example, for the default branch). Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results. For more information about GitHub code scanning, check out the documentation.

[heinpa]

Note that the checks executed as part of this PR are exactly the ones that are proposed.

test-python cannot succeed at this point, because tests were not updated to reflect changed behaviour on the current master branch (this is partly why I wanted to introduce this action). Updates to the tests are proposed in PR 349.

test-java fails because OPENAI_API_KEY is supposedly not set. However, it does exist in the repository secrets and is referenced as environment variable in the workflow file. So I'm not quite sure what's wrong here.

@anbo-de @Perevalov I would appreciate a review and help with the remaining issues to get these workflows running.

[heinpa]

This pull request sets up GitHub code scanning for this repository. Once the scans have completed and the checks have passed, the analysis results for this pull request branch will appear on this overview. Once you merge this pull request, the 'Security' tab will show more code scanning analysis results (for example, for the default branch). Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results. For more information about GitHub code scanning, check out the documentation.

Code scanning with CodeQL has been removed from this PR again. It would require separate building of the Qanary project beforehand, which is not yet implemented as an independent script.

[heinpa]

Live tests are no longer executed as part of the workflow

[heinpa]

Seems like because there is no more space left, not all packages can be installed while testing python components. This of course means the tests fail.

ERROR: Could not install packages due to an OSError: [Errno 28] No space left on device ./service_config/test_python_components.sh: line 15: pytest: command not found

SOLVED by adding a cleanup step after tests. I have also added a summary at the end of the script for python tests.

[heinpa]

The Python tests script is taking a long time to run, compared to the one for Java components. I assume this is because of the re-installation of the requirements with pip (since the environment is created new for every component). Is there a better way to handle this?

I avoided a shared environment, mainly because it allows "laziness" when defining the individual requirement files for components.

EDIT @anbo-de @Perevalov I've now moved to a shared environment for all Python components, which speeds up the process quite a bit. Please share your thoughts on this!

[heinpa]

@anbo-de requested changes have been added and subshell for building Qanary dependencies locally was removed.

There are now also exclusions for submodules:

TEST and BUILD:

• Python: excluded using submodules list
• Java: submodules must not be included in reactor -> a check is included

DEPLOY:

• automatic deployment via microservice updater relies on explicit configuration of services in service_config.json -> don't include submodules