LOM2M/Gitlab-configuration-and-CI-CD.md

+The Continuous Integration (CI) is configured thanks to the `.gitlab-ci.yml` file in the repository.
+
+The actual CI uses docker to run all stages of the CI.
+
+
+To avoid the trigger of the CI pipe-line you can use the following at commit time:
+In the commit message you can add some keywords to prevent the tests or the whole CI to be execute:
+- Add `(skip-tests)` in the commit message to skip tests in CI
+- Add `(skip-ci)` in the commit message to skip the whole CI process
+
+
+
+Here is an example of a full CI pipe-line executed when a release tag is added:
+![Capture_d_écran_2021-01-22_à_11.45.17](uploads/dad16964ef05acf3aa6cf5f2c967e4f0/Capture_d_écran_2021-01-22_à_11.45.17.png)
+
+
+# Phases of CI
+
+## Build
+
+During this phase, all the necessary docker images are built if necessary.
+
+- **LOM2M**: docker image including a compiled version of the LOM2M (emulator) version
+- **LOM2M ESP**: docker image including an environment to build LOM2M for an ESP target and check there is no issue
+- **JMETER**: a JMeter image is used to execute all the tests (REST API)
+- **Monitor**: this image uses the monitor (Java) proposed by Eclipse OM2M to receive notifications and send ACK
+
+## Tests
+
+In this phase different steps are executed:
+
+- ** TBD **: integration of the ETSI test case collection to check all the attributes (cf. #156)
+
+- **Functional Tests with JMETER**: this step executes tests to check the oneM2M REST API of LOM2M. The tests, (available in the `tests/jmeter` folder) will check the behavior on the oneM2M resources (such as AE, CNT, CIN, SUB, etc.). The aim is to ensure the platform is still working after an update.
+
+- **test LOM2M persistence**: the aim of this test case is to check the behavior of the backup feature. However, due to the execution in docker (or docker in docker) the expected results are not always working as intended. This should be improved.
+
+- **test ESP build**: this step will execute a build of the ESP sketch to ensure it still builds properly.
+
+- **Code quality**: executes the code quality plugin to check if the code quality has improved or not with the latest contribution. However, this analysis does not go far in depth. It may trigger some warnings if comments such as TODO or else are found left in the code. This step produces a JSON report as an artifact available to download.
+
+
+
+## Release
+
+The release phase is triggered only on master branch. Two jobs are defined:
+
+- Release latest: will tag the pre built image of LOM2M as the `latest` version available at any merge or commit in the `master` branch. The image is added to the gitlab package repository.
+
+- Release tag: will tag the pre built image of LOM2M as the `x.x.x` version of the software. This image is added to the package repository of the gitlab.
+
+
+## Jobs dependency 
+
+To optimize the execution of the CI, the specified jobs are defined using _needs_ to accelerate the execution of the pipeline.
+
+Here is the corresponding diagram:
+![Capture_d_écran_2021-01-22_à_11.45.10](uploads/9951dddb10158374ab047336a76bcb67/Capture_d_écran_2021-01-22_à_11.45.10.png)
+
+This will enable some tests to start as soon as their prerequisite are available.
+
+For instance, the test LOM2M ESP Build only needs the LOM2M ESP BUILD image to be available. 
+This enables the ESP BUILD test to start as soon as the LOM2M ESP image is built.
+
+However, the functional tests require the LOM2M, JMETER, and MONITOR images to run.