...
There is also another file in the codebase called, called application-keycloak.properties, containing all required properties (uri, realms, etc..) for keycloak communication, and the following property as William mentioned needs to be set to true to enable multi-tenancy.
...
So, in order to run tests (which are written in Scala and Gatling framework), we should setup keycloak correctly by creating required realms, roles and users (please find the sequence diagram attached).
Setting up keycloak could be done easily by importing a pre-configured json file. For our local test, It it has been done with a docker file and two json files attached.
The final step is running tests through a command line: mvn gatling:test
...
Looks like a full CI/CD chain is not needed , - a CSIT testsuite look more acurate...looks more accurate as only a subset of AAI pods + keycloack are needed for the tests => functional tests, no need to deploy a full ONAP
Lasse Kaihlavirta wrote some documentation for this these kind of tests: Moving CSIT to project repositories
the idea would be to keep the hand of the tests on AAI side , - create a jenkins csit for jenkins that will
- start the AAI pod
- post configure the pods
- deploy keycloack
- deploy the tester
- cleanup
These jenkins testing
...
jobs could be triggered
...
on any patchset as part of the functional verification tests
...
as well as on merge (but not on daily basis without custom JJB configuration) - see Project-specific CSIT structure
Current daily CSIT tests (most of the time not very well maintained) can be found here: https://jenkins.onap.org/view/CSIT/