Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 9 Next »

Repositories

Code is contained within the following Git repositories.

Branches

The 'master' branch is for the release currently in progress. There are alternate branches for past releases. (e.g. 'Casablanca').

Code Submissions

Information on how to utilize Git and Gerrit to submit new code is available here: Configuring Gerrit.

Tips on code submission best practices are available here: Commit Messages.

When submitting to non-core POMBA repositories, it's helpful to label the submission with 'pomba', both for ease of filtering and batch reviewing.

JIRA Workflow (Submitted)

When all code submissions for a JIRA issue have been made, the JIRA issue should be transitioned from 'In Progress' to 'Submitted' to keep people informed.

Code Reviews

Code reviews are performed in Gerrit.

Committers

Make sure to add appropriate committers (as well as reviewers) to submissions so that they can provide them with "+2" reviews, allowing for a merge to be done.

Note: For some projects (and maybe more in the future), comitters may not be from the same company as the submitter.

Note: Comitters are subject to change so make sure you're up to date!

Gerrit Commands

Refer to Development Procedures and Policies#MagicWords for information about special "replies" that can be used to invoke actions.

Code Merges

Once code submissions have been made and a "+2" review has been received, authorized committers may then merge the change into a branch.

JIRA Workflow (Delivered)

Once all code submissions related to the JIRA issue have been merged into their respective project branches, the JIRA issue should be transitioned from 'Submitted' to 'Delivered' to inform others that, should they deploy ONAP, this feature, functionality or bug fix will be available.

Sonar Results

Once code is merged and a Sonar job is run, the results of the scan should be checked to ensure that proper line coverage has been met and there are no major vulnerabilities detected. If there is a lack of coverage or vulnerabilities reported, they should be addressed, preferably immediately, though a bug could be entered to prioritize and track this required work.

Refer to the POMBA Build Process section for more details.

Build Jobs

Verify Jobs

The verify jobs are engaged when code is submitted to the repository in order to confirm builds wouldn't break due to the inclusion of the change.

'ONAP Jobbuilder' events will appear in the Gerrit review.


Merge Jobs

The merge jobs are engaged when a committer allows a code change to be added to a branch in the repository.


Docker Jobs

The Docker jobs build docker images and upload them to Nexus.


Release Jobs

...


Sonar Jobs

The Sonar jobs perform a code-quality scan of the repository to ensure that best practices are adhered to and vulnerabilities are addressed.

Nexus

Artifacts produced by build jobs – e.g. Docker images – are stored in Nexus.

https://nexus3.onap.org

Sonar Reports

Sonar provides a dashboard of metrics related to code repositories that should be checked to ensure that quality thresholds are being met.

Line Coverage

Each project institutes a certain threshold for line coverage that must be upheld. If code submissions result in line coverage dipping below this threshold, this will eventually be noticed and cause trouble for the developers. (In Dublin Logging, the threshold is 50% but this is subject to change.)

After completing work on a story or bug, Line Coverage should be checked to ensure that thresholds are met. (It's best to have higher coverage than required in order to be able to accommodate future code submissions, particularly if/when the current threshold is raised.)




  • No labels