... | ... | @@ -12,10 +12,17 @@ |
|
|
</tr>
|
|
|
</table>
|
|
|
|
|
|
## Table of Contents ##
|
|
|
|
|
|
* [Merge Request Workflow Presentation](#merge-request-workflow-presentation)
|
|
|
* [Committee Role](#committee-role)
|
|
|
* [Merge Requests and Review Rules](#merge-requests-and-review-rules)
|
|
|
|
|
|
In our humble opinion, a good developer is not just someone who follows a programming workflow and writes high-quality code.
|
|
|
A good developer knows how to deliver code for review and make the whole code review process effortless for the reviewer.
|
|
|
A good merge request should solve a specific task. We suggest not including more than one feature in one merge request. It would be much better if you created several merge requests instead.
|
|
|
|
|
|
----
|
|
|
|
|
|
## Merge Request Workflow Presentation ##
|
|
|
|
... | ... | @@ -30,6 +37,7 @@ Regarding the CI results analysis, the following tests are unstable and may be d |
|
|
- eNB-CI-MONO-FDD-Band13-X2HO-B210
|
|
|
- eNB-CI-TDD-Band40-B210
|
|
|
|
|
|
----
|
|
|
|
|
|
## Committee Role ##
|
|
|
|
... | ... | @@ -49,16 +57,42 @@ The Technical Committee is responsible for the following tasks: |
|
|
6. Close tickets and delete branches upon task completion.
|
|
|
7. Review all the policies to be in-line with state-of-the-art development tools
|
|
|
|
|
|
----
|
|
|
|
|
|
## Merge Requests and Review Rules ##
|
|
|
|
|
|
A Merge-Request can be submitted as soon as the code is considered stable and reviewable.
|
|
|
|
|
|
### Creation of a Merge Request ###
|
|
|
|
|
|
**At the creation time**, you, as a developer, **SHALL** add at least **one** label to your Merge Request:
|
|
|
|
|
|
* ![BUILD-ONLY](lbl-images/lbl-build-only.png) will only perform BUILD stages in pipelines and not testing
|
|
|
* ![4G-LTE](lbl-images/lbl-4g-lte.png) will perform the whole 4G/5G test-suite
|
|
|
* ![5G-NR](lbl-images/lbl-5g-nr.png) will perform all builds, a limited 4G test-suite and the full 5G test-suite
|
|
|
* ![CI](lbl-images/lbl-ci.png) will perform the whole test-suite. This label is reserved to the CI team (especially when doing integration branches).
|
|
|
|
|
|
In the GitLab Merge Request creation interface, you click on the little arrow at the end of the label field and select one:
|
|
|
|
|
|
![creation MR](lbl-images/label-at-creation.png)
|
|
|
|
|
|
You can also add a label once your Merge Request has been submitted. On the left column:
|
|
|
|
|
|
![add label](lbl-images/add-label-edit.png)
|
|
|
|
|
|
If none of these mandatory labels is present in your Merge Request description, the CI pipeline won't run and you will get a notification on your MR web-page.
|
|
|
|
|
|
![like this](lbl-images/no-label-comment.png)
|
|
|
|
|
|
**On test side**, the MR triggers the CI pipeline to test the proper integration into the current develop branch.
|
|
|
The developer is primarily responsible for manual inspection and pre-filtering of the CI results.
|
|
|
The CI team is of course available to review the results and re-run some tests individually to dispel any doubts.
|
|
|
|
|
|
Once the CI is passing (pre-requisite), the MR can be tagged READY_TO_BE_MERGED, developers **shall not push again to that branch**
|
|
|
Once the CI is passing (pre-requisite), the MR can be tagged ![READY_TO_BE_MERGED](lbl-images/lbl-ready-merge.png), developers **shall not push again to that branch.**
|
|
|
|
|
|
In fact, if you push again to the source while having the ![READY_TO_BE_MERGED](lbl-images/lbl-ready-merge.png) label, this label is **blacklisted** and won't trigger CI.
|
|
|
|
|
|
### Peer Review of a Merge Request ###
|
|
|
|
|
|
**On review side**, in parallel to the testing process, TC members or peer developers are tasked to perform a human code review.
|
|
|
|
... | ... | |