|
|
<table style="border-collapse: collapse; border: none;">
|
|
|
<tr style="border-collapse: collapse; border: none;">
|
|
|
<td style="border-collapse: collapse; border: none;">
|
|
|
<a href="http://www.openairinterface.org/">
|
|
|
<img src="../images/oai_final_logo.png" alt="" border=3 height=50 width=150>
|
|
|
</img>
|
|
|
</a>
|
|
|
</td>
|
|
|
<td style="border-collapse: collapse; border: none; vertical-align: center;">
|
|
|
<b><font size = "5">OAI Software Alliance Merge/Pull-Request Policy</font></b>
|
|
|
</td>
|
|
|
</tr>
|
|
|
</table>
|
|
|
|
|
|
## Table of Contents ##
|
|
|
|
|
|
1. [Creation of a Merge-Request](#1-creation-of-a-merge-request)
|
|
|
2. [Merge-Request and Continuous Integration](#2-merge-request-and-continuous-integration)
|
|
|
2.1. [Continuous Integration Feedback](#21-continuous-integration-feedback)
|
|
|
----
|
|
|
|
|
|
Merging is usually a non-automated procedure when a contributor requests his work to be merged into a main branch.
|
|
|
Usually contributors are not allowed to merge directly into a main branch.
|
|
|
|
|
|
* Git repository hosts such as GitHub and Bitbucket choose the name **pull request** since the first manual action would be to pull the feature (source) branch.
|
|
|
* Git repository hosts such as GitLab and Gitorious choose the name **merge request** since that is the final action requested.
|
|
|
|
|
|
# 1. Creation of a Merge-Request #
|
|
|
|
|
|
When creating, the developer **SHALL** provide the following information:
|
|
|
|
|
|
* Short Title
|
|
|
* Link to the Ticket/Issue ID
|
|
|
* Add the proper labels:
|
|
|
- Kind such as (<img src="../images/enhancement-label.png" /> or <img src="../images/bug-label.png" />)
|
|
|
- Functional
|
|
|
|
|
|
# 2. Merge-Request and Continuous Integration #
|
|
|
|
|
|
Opening a Merge-Request **does automatically trigger one or several job(s)**.
|
|
|
Continuous Integration could de-centralized over several servers belonging to OSA members.
|
|
|
|
|
|
The OAI Continuous Integration workflow is described in the following picture:
|
|
|
|
|
|
<img src="../images/CI-workflow.png" />
|
|
|
|
|
|
## 2.1. Continuous Integration Feedback ##
|
|
|
|
|
|
The Continuous Integration process automatically provides feedback to developers and integrators in a form of:
|
|
|
|
|
|
* email to Merge-Request author with attached HTML reports
|
|
|
* pass/fail status in the OAI slack channel [ci-enb](https://openairinterface.slack.com/messages/CB71HBZ55)
|
|
|
* comments in the GitLab Merge-Request web-page:
|
|
|
- a status on the OAI formatting rules: do the modified files by the MR follow the rules?
|
|
|
- a status on compilation warnings: do the modified files by the MR introduce new warnings?
|
|
|
- a pass/fail status with an URL link to the Jenkins CI build
|
|
|
|
|
|
In parallel, Jenkins and GitLab integration allows to create an external "pipeline" with different jobs.
|
|
|
|
|
|
* Each job has a pending, running, pass or fail status
|
|
|
* We have jobs for different build variants and different test variants |