* The script is a direct derivation of the original one and can be
merged in a near future
* The script search for the latest updated MR in the project repository
to retrieve the source branch
* Then merge the MR on the layer project according to the recontructed
integration branch

* This commit adds the script to check if the integration branch is
up-to-date on the layer side
* Very few modification with respect to the original script
* The script can be merged with the original one in the near future

* The script is derived from the integrate_into_manifest file and is
used to create the integration branch on layers
* The script create a new branch with the modifications on the
SRCREV.conf indicated as parameter and on the bitbake recipe indicated
* In a future this file could be merged with the integrate_inot_manifest
one

* The file is intended to contain all the automation tasks to be
executed by the projects used in the Yocto layers
* The steps are the main steps that this CI file contains:
  - Every time a MR is opened on a project an integration branch is opened
 on the layer which updates the SHA of the commit on the
'conf/SRCREV.conf' file referring to correct bb recipe
  - A MR is automatically opened on the layer master branch, that triggers all the
downstream job of the manifest-integration file, which is left untouched
  - A check job checks that the layer project branch is up-to-date with
the commit revision
  - Once the MR is accepted on the project, the one in the layer is
merged and closed by default after having tried a rebase.
* Minor bug fix on gitlab-ci.yml file

* The script is identical to the 'scripts/deploy_gitlab_ci_projects.py'
apart from the fact that does look for a manifest project to
integrate/merge
* In the future the two scripts may be merged to treat both cases
correctly, for now we skip this part

* The .gitlab-ci submodule is added also to other groups (those
containing kernel, uboot, etc.) so it is necessary to create an
integration branch also them

* The variable is necessary when the GitBot will be given access to
sveral groups to restrict the search for the manifest repository
* Add --verbose option and other debug stuff in merge job

* The SW artifacts with the same name are overridden
* Bug fix on notification.json file search

* Bug fix on Azure path

* When a tag occurs the '-b' command in repo init would fail

* Insert trigger rule allowing to build/deploy/notify on tag creation
* In deploy-on-tag job the artifacts are uploaded to the official SECO Azure
container with dedicated token, stored as 'yocto_ng' group variable
* The commit should fix the error in notify job

* The job will be taken in charge by the runner with 'infrastructure'
tag

* Change syntax rule

* Change syntax rule

* This commit insert the schedule in the workflow rules allowing to trigger build, deploy, notify on a scheduled basis
* Bug fix on variables

* The build job is now triggered on schedule

* Without this fix the branch used for the build is always the
kirkstone/develop one

* The jobs will be uncommented in the next future for testing purpose

* Update README.md and files in the doc folder to fit the new version
 of CI/CD config files
* Update variables in common file to fit the newly created Docker images
* Insert C31 board build and deploy jobs
* Remove files used in previous integration tests