This page explains what basic things each OPNFV project needs to do in order to enable the CI for the project.

It is not complete and will evolve together with OPNFV itself.

Please note that this guide assumes the Git and Gerrit related stuff have already been set up for the project you are working on.

If the project has already been approved by TSC but Git/Gerrit has not been set up yet, contact LF right now by sending mail to opnfv-helpdesk@rt.linuxfoundation.org together with the details of the project and get it done.

• Determine the scope of commit gate testing for every patch
• List what to test/check on Commit Gate for your project on Etherpad –> https://etherpad.opnfv.org/p/octopus
• Determine the scope of master branch testing
• Add/Modify Jenkins Jobs

Commit gate testing is done automatically upon arrival of a new patch and helps us to keep the quality of master branch above certain level and enforce standards for example how to format the commit message. It also provides feedback regarding the quality of the commit by scoring and adding information on Gerrit.

If a commit fails to pass these tests, they won't get merged to master.

Since each project has its own nature, requirements, and languages used for implementation, it is natural to have different type of tests in commit gate. Therefore, you must determine what you want to test when a new patch is submitted to protect the quality and give feedback.

An important thing to keep in mind while deciding the scope is that the commit gate testing is generally the shortest loops in CI. So, the time it takes to run the commit gate testing should be reasonable.

For example, OpenStack Gate Tests could take up to 1 hour in some cases. But faster is better so we don't build up the queue in Gerrit which could result in tricky merge situations and in CI which could increase the feedback time.

Here are some examples regarding what could be run in commit gate on each and every patch.

• commit message check
• style/lint
• unit test
• basic build
• subset of integration tests

See the corresponding flow from this link.

Master Branch Testing involves more extensive testing on fully deployed system based on latest on master branch and takes longer time to execute.

The steps that could be run in this type of testing is listed below.

• Building the installer
• Deploying the OpenStack/OpenDaylight using the installer
• Running full/selected Tempest Test Suite against the deployed system
• Running full/selected Robot Test Suite

Due to nature of the testing, the time it takes and the resources needed to execute these tests are quite different than Commit Gate tests. These tests are generally executed periodically (every night for example), manually, or based on certain Gerrit events that occur less frequently than submission of new patches.

See the corresponding flow from this link.

All the projects that were created and approved on or before 2015-02-10 have initial/basic jobs created on OPNFV Jenkins, https://build.opnfv.org/ci/.

If you are a project creator or committer, you either need to contact Octopus team to get help regarding how to set up/configure jobs for your project or do this yourself.

If you prefer to do this yourself, please follow the steps listed on the page https://wiki.opnfv.org/octopus/jenkins_wow.

• OpenStack Project Creators Guide: http://docs.openstack.org/infra/manual/creators.html
• OpenStack Development Flow: http://docs.openstack.org/infra/manual/developers.html
• OpenStack Project Infrastructure: http://ci.openstack.org/
• Understanding the OpenStack CI System: http://www.joinfu.com/2014/01/understanding-the-openstack-ci-system/
• The OpenStack Gate: https://dague.net/2013/02/21/the-openstack-gate/
• Automatic Gatekeeper: http://doc.bazaar.canonical.com/latest/en/user-guide/bazaar_workflows.html#decentralized-with-automatic-gatekeeper