Verification jobs on Integration repositories

Status of verification jobs related to Integration repositories

Repository	Verification job	tests	linting	comments	Jira tasks

Repository	Verification job	tests	linting	comments	Jira tasks
integration	Yes	Yes	Yes	code coverage: 99%	INT-1427: Setup tox in integration repoClosed INT-1434: Setup Vagrantfiles validation in integration repoClosed INT-1436: Setup golang validation in integration repoClosed INT-1451: Fix linter issues in Integration repoClosed INT-1508: Setup Docker Compose based projects verification jobsClosed INT-1529: Implement unit tests for provisioning management service provider for 5G NRM CMClosed
integration/csit	Yes	Yes	No	launch CSIT tests of the project involved in the patch	repository to be archived one day or another as current csit tests are functional tests to be reonboarded at project level
integration/docker	No	No	No	docker build, chains need created to build docker and push them to nexus or docker hub	delayed..as everything is working fine on gitlab.com..
integration/xtesting	No	No	No	docker build chain needed to build docker and push them to nexus or docker hub	delayed..as everything is working fine on gitlab.com..
integration/simulators/ran-simulator	Yes	No	Yes	basic verifiers added up to this point	INT-1491: Add INFO.yaml verification job in integration/simulators/ran-simulator repoClosed INT-1492: Setup CI jobs for integration/simulators/ran-simulator repoClosed
testsuite	Yes	No	No	3scm-docker-shell-daily? Build of the robot docker We could add robot lint	INT-1478: Robot script minor changes (linter)Closed
testsuite/oom	No	Yes	No	no helm lint or tests JobDeployer (Gating)	INT-1433: Add INFO.yaml verification job in testsuite/oom repoClosed
testsuite/heatbridge	Yes	Yes*	No	no helm lint or tests	linter added
testsuite/testing-python-utils	Yes	Yes	No	*: test target but 0 test pylint available in tox pylint launched manually score 0.34/10
demo	Yes	??	Yes		INT-1482: Deploy verification jobs in Demo repositoryClosed
integration/usecases/bbs	Yes	no	yes

Notes

integration/benchmark and integration/devtool are archived
integration/seccom is not managed by us
testsuite/properties to be archieved soon: files have been relocated
in demo we can find python, java, c and lot of descriptor files, the README does not seem very up to date (ref to Beijing)

the pylint rate and code coverage is globally very low, lots of place for improvements... :)

Regarding more specifically the integration repository

we have different type of files corresponding to different projects
python (vcpe, hpa, mocks, s3p) - the pylint rating correspond to the 4 modules
go (security)
yaml
bash

I just created a tox.ini for the python based project and run pylint + nosetests for the unit tests - but there are no unit tests in the different python directory :)
it seems that s3p is only for python2.7 which is no more supported.

I did not run bashhate (quality of bash files) or yamllint (yaml file)
I also found a robotframework linter (from Nokia), and run it on testsuite repo, see results attached

W: 64, 100: Line is too long (exceeds 100 characters) (LineTooLong)
W: 71, 100: Line is too long (exceeds 100 characters) (LineTooLong)
E: 39, 0: No keyword documentation (RequireKeywordDocumentation)
E: 47, 0: No keyword documentation (RequireKeywordDocumentation)
E: 69, 0: No keyword documentation (RequireKeywordDocumentation)
+ robot/resources/msb_interface.robot
W: 9, 100: Line is too long (exceeds 100 characters) (LineTooLong)
+ robot/resources/stack_validation/packet_generator_interface.robot
W: 2, 100: Line is too long (exceeds 100 characters) (LineTooLong)
W: 23, 100: Line is too long (exceeds 100 characters) (LineTooLong)
E: 123, 0: No keyword documentation (RequireKeywordDocumentation)
+ robot/resources/stack_validation/validate_dns_scaling.robot
W: 27, 100: Line is too long (exceeds 100 characters) (LineTooLong)
W: 33, 0: Too few steps (1) in keyword (TooFewKeywordSteps)
^....

Open questions:

does it make sense for us to improve that by introducing python/bash/yaml verification when we submit code..
shall we apply some quality rules on the dev done by integration contributors (integrated in the jenkins jjb) within integration activities (most of us are integrators not necessarily developpers)
shall we focus only on the most recent developements only -e.g. vCPE from Bartek?)
how do we proceed with python 2.7 code, shall we migrate it? delete it from the repo?