Before every release, a scan of vulnerabilities on 3pp must be done.
NexusIQ
Committers have access to NexusIQ reports, where a more straightforward list of vulnerabilities and its levels is available, showing if it’s a direct dependency or transient. The report is generated on maven-clm-master jenkins job (i.e: https://jenkins.onap.org/view/policy/job/policy-api-maven-clm-master/ ). NexusIQ can be installed as a plugin in IntelliJ. Log into ONAP nexus (https://nexus-iq.wl.linuxfoundation.org/ ) and generate an user token. Use that as User Authentication and test with Connect. If it works, then for each repository, select the correct Application.
After that, when opening pom.xml files, it will highlight any dependency with issues. Not all issues can be fixed, but it gives a good idea of how many dependencies need to be watched.
SonarLint / SonarCloud
Any member of ONAP can get SonarLint plugin in IntelliJ to be connected to ONAP SonarCloud.
Go to https://sonarcloud.io/organizations/onap/projects?sort=maintainability and login with GitHub (you need to ask your GitHub account to be added to ONAP organization https://github.com/onap ). Generate an user token to be used on SonarLint plugin.
To configure SonarLint, you need to have nodejs installed. On the SonarLint settings tab, use Connected Mode and login to ONAP SonarCloud. Use the token generated on previous step. It will use the ONAP rules for clean code.
To run, click on each module (don’t run analysis over the whole project, it will take too long and will analyse unnecessary files from target folder) and go SonarLint → Analyse with SonarLint. Fix anything you deem fixable.
Updating Maven Dependencies
Most of Policy dependencies are at the parent/integration/pom.xml file. Versions can be changed at property level (i.e <version.spring>) or at dependency version tag. Other dependencies are on project level, so be careful when changing something from integration pom.xml that causes conflict with project level dependencies. Upgrade both if necessary.
Use Maven Repository (https://mvnrepository.com/ ) as reference for the latest. Keep in mind to use actual released versions (avoid alpha or pink version). MVN Repository can also inform if a dependency is vulnerable.
Suggestion: try to upgrade versions one by one or by cascade group (i.e hibernate have a few different dependencies, so they should be upgraded together; same with spring/spring-boot/spring-security)
When changes on integration pom.xml are done, mvn clean install must be ran in ALL repos.
Here are some bash scripts that could help with that. Download them to the parent folder of all policy repos. If your folder structure is /git/policy/parent, the script should be downloaded in the /git/policy folder.
this will run mvn clean install in each repo, one by one, following dependency order. (parent - docker - common - models - etc…). If the build fails, the script generated a <repo>.log file inside the repo folder (api would generate an api.log file inside its folder - /git/policy/api/api.log) where the issue is reported.
After all repositories are building successfully, CSITs must be ran to guarantee all applications are starting correctly and executing the test cases.
this will generate all docker images used in Policy Framework.
this will remove all docker images, given a name start. It’s good to use when generating local images a few times, so it can be used ./remove-docker-images.sh onap/ to remove all local images.
Before running the tests, go to the /git/policy/docker/compose/get-versions.sh script and set the variable LOCAL_IMAGES=true so it will pick up the newly generated images instead of downloading from nexus.
How to run CSITs using docker compose: https://docs.onap.org/projects/onap-policy-parent/en/latest/development/devtools/testing/csit.html#id2
Rinse and repeat.