This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
octopus:project_guidelines [2015/03/01 12:36] Fatih Degirmenci [Scope of Master Branch Testing] |
octopus:project_guidelines [2015/03/01 13:07] (current) Fatih Degirmenci |
||
---|---|---|---|
Line 7: | Line 7: | ||
Please note that this guide assumes the Git and Gerrit related stuff have already been set up for the project you are working on. | 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. | + | If the project has already been approved by TSC but Git/Gerrit has not been set up for it 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. |
====== Steps to Take ====== | ====== Steps to Take ====== | ||
- | * Determine the scope of commit gate testing for every patch | + | Here is the list of steps to take in order to enable CI for each project. See details section for more information. |
- | * 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 | + | * Determine what to check/test in Commit Gate for every patch for your project |
+ | * List what to check/test in Commit Gate for your project | ||
* Add/Modify Jenkins Jobs | * Add/Modify Jenkins Jobs | ||
====== Details ====== | ====== Details ====== | ||
- | ===== Scope of Commit Gate Testing ===== | + | ===== What to Check/Test in Commit Gate ===== |
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. | 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. | + | If a commit fails to pass these tests, it won't be merged to master until it passes commit gate. |
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. | 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. | + | An important thing to keep in mind while deciding the scope is that the commit gate testing is generally the shortest/fastest loop 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. | 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. | ||
Line 40: | Line 41: | ||
See the corresponding flow from [[octopus:flows#gerrit_verificationdeveloper_flow|this link]]. | See the corresponding flow from [[octopus:flows#gerrit_verificationdeveloper_flow|this link]]. | ||
- | ===== Scope of Master Branch Testing ===== | + | ===== Provide Input ===== |
- | Master Branch Testing involves more extensive testing on fully deployed system based on latest on master branch and takes longer time to execute. | + | Please provide your input on Etherpad, https://etherpad.opnfv.org/p/octopus. |
- | + | ||
- | 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 [[octopus:flows#master_branch_flow|this link]]. | + | |
===== Jenkins Jobs ===== | ===== Jenkins Jobs ===== | ||
Line 62: | Line 52: | ||
If you prefer to do this yourself, please follow the steps listed on the page https://wiki.opnfv.org/octopus/jenkins_wow. | If you prefer to do this yourself, please follow the steps listed on the page https://wiki.opnfv.org/octopus/jenkins_wow. | ||
+ | |||
+ | We encourage/advise you to contact Octopus Team first for Jenkins related questions, especially during this phase. | ||
====== Further Reading ====== | ====== Further Reading ====== |