In the current implementation of Edgehog project, manifest
repositories do not have to contain SRCREV.conf files which are
instead in the conf/SRCREV.conf file of the meta-layer. For this reason
we want to avoid to throw an error when the file is not found
inside the manifest.

* Since the number of custom projects and thus of GitLab groups and
repositories to which the CI/CD steps need to be deployed, jinja2
rendering is introduced in the same way as it was done for the manifest
integration steps.
* Define the INTEGRATION_CI project variable for this repository in
order to define a list of group, manifest repository and branch name to
which the gitlab-ci shall be integrated.
* Use the mechanism of dynamic child pipeline creation.
* Update documentation according to the modifications.

* Insert new section describing all the necessary steps and settings to
include a new project in the CI/CD integration flow
* Insert description of dynamic child pipelines creation for manifest
pipeline
* Insert instructions on how to deploy the GitLabCI to custom projects

These changes are necessary since the mani manifest pipeline is
triggered from a parent pipeline and the rules need to be adapted
according to this.

* Change name of DEFCONFIG_FILE and BUILD_DIRECTORY variables in order to
allow compatibility of the CI/CD also for custom projects
* Insert graphic backend information in the IMAGE_NAME variable
* Fix onvarible assignment for layers integration

* Inserting these rules allow to retrigger pipelines in MR in case some
of the jobs failed
* Insert yamllint control also on masifest pipeline
* Remove some debug echos
* Minor bug fix

* As of now no control were performed over yaml syntax and some fixes
were necessary.
* Increase yaml file line length max value to 200

* The cancel-previous-pipeline job aims at reducing dead time. Indeed,
everytime we push a new commit to a branch, a new pipeline is created.
Often the pipeline for the previous commit has not finished yet, and
GitLab does not automatically cancel it. It consumes valuable build
time, even if we don't need the results anymore. This adds a MR pipeline
job to search for previous pipelines on the same branch and cancel
them explicitly.
* Add yamllint job allowing to check for correct yaml syntax in the
dynamic child pipeline created in the layers and manifest integration
jobs.
* Add yamllint job also on .gitlab-ci pipeline.

This commit introduces major changes in the layers integration steps
performed every time a new MR is opened in one of the BSP repositories.
More in detail:

* Introduces jinja2 templating tool to perform dynamic child pipeline
and dinamically assign the INTEGRATION variable value to the CI jobs.
* The main layers-integration.yml file only contains check and trigger
pipelines to create a dynamic downstream pipeline.
* Introduces layers-integration-jobs.yml that is dinamically assigned
with the variables from the INTEGRATION variable and that executes all
the main tasks of layer integration pipelines

The ideas behind this refactoring are the following:

* Introduce dynamic child pipelines also for pipeline running on the
manifest. This in particular allows to dynamically creates a .yml
configuration file containing all the board jobs via jinja2 templating
tool. With this approach it will only be necessary to define three main
variables in the manifest or in the CI/CD variables of the manifest
repository:
	* MACHINES: a list of the machines of which the build is
necessacy
	* DISTRO: a list of the Edgehog distros
	* GRAPHIC_BACKEND: a list of the graphic backends supported
* Introduce a generic manifest-pipeline.yml that is used both by the
pipeline on the test and general manifest and that simply generates
the final .yml file doing all manifest CI/CD tasks.
* Introduce a generic build-pipeline.yml file containing only the
definition of the main jobs used in the manifest CI/CD (i.e. build,
deploy, test, changelog, etc.).
* Refactor manifest-pipeline-yocto.yml to simply stores variables and
include the other .yml files thus allowing the other steps to be better
tested in the testing group.

* Delete all the content of the boards/ folder containing the job
configuration files for the different boards. The idea behind it is to
use a dynamic child pipeline from a dinamically created .yml file
(containing all the board jobs), thus simplifying maintenance,
avoiding copy and paste errors and allowing to dinamically define as a
global variable the list of machines to be built/deployed/testes.
* Delete files initially imported from SECO-NE original project and no
longer necessary.

Up to now, the ci-test group repositories were used for sporadic
tests but in the optic of a continuous CI/CD improvement they need
to be treated as 'production' repositories. With this approach,
every time a MR is created in the gitlab-ci repo, the modifications
introduced can be tested in the ci-test group repositories.

* The jinja2 templating is inserted for manifest integration steps
in order to use dynamic child pipelines.
* A new job is generated before the integration actually starts that
create the manifest integration jobs, allowing to correctly use
the INTEGRATION global variable.
* Move manifest-integration-jobs to a dedicated yaml file.

* Insert configuration file for boards based on Intel Tiger Lake boards

* Set the number to 32 and increase number of parallel jobs for the
runner

* Increase the timeout to 4h because of increased overload on CI/CD
pipeline

* Remove c61 config file since not released yet

* Fix on AZURE_PATH variable position

* The configuration file allows to build 3 different RAM
configurations: 2x256M, 4x256M, 4x512M
* Insert preliminary test integration job

* Add configuration file for 928 considering all the supported RAM
configurations
* Insert RAM_CONF parameter than need to be set inside local.conf
file at build time

* Insert configuration file for C61 iMX8MM SBC board
* Insert configuration file for D18 iMX8MP SMARC board
* Insert configuration file for D23 PX30 SBC board
* Use same ssstate-cache folder of C31 SBC for D23 SBC

* Insert the parameter BB_NUMBER_THREADS defining the maximum number of
tasks BitBake should run in parallel at any one time (default set to 64).
* Insert the parameter PARALLEL_MAKE specifying extra options that are
passed to the make command during the compile tasks (default set to 64).

* Include a list of repositories whose name appears in the MR on
meta-layers regarding BSP changes
* Include this MR from Gitbot because they bring information regarding
the BSP itself

* The Edgehog project is not using anymore the forked repository but the
original one in GitHub

* Parameter necessary to submit test job

* First implementation of LAVA testing of Edgehog Embedded Full Image
* First support for A62, C20, C26, C43, C12
* The test is executed every time a new build is executed by triggering
it manually or on schedule (allow to fail rule)
* Change rule for deploy, changelog to manually run on MR

* An error in compiling .wic image is given when building Intel Apollo Lake
image

* This is necessary since seco-ne boards does not have .dtbo but only
.dtb

* Instead of using two containers all custom projects are deployed to
the same container

* For custom project stable releases a dedicated container as been created

* Include config file for Elkhart Lake Intel processor
* Include embedded jobs also for Intel Apollo Lake processor
* Minor fix in check artifacts task