* Since now the links available in the notification message displayed in
  Teams channel with the link, changelog and job results report were
broken for software artifacts in private container.
* Introducing the creation of read-only SAS token with 6-months
  expiration policy also for reports.
* Fix in deploy stage for software artifact URL generation in case of
  public containers.

* For software artifacts that are saved within private Azure container
  it is necessary to add a blob SAS token in order for the URL to
correctly work. For such purpose we include the generation of a 6-months
duration read-only SAS token to be attached to the URL.
* Add AZURE_STORAGE_KEY among necessary CI/CD variables.

* Since now, for each project, the script was searching only for MRs
that were merged into branches having the same name of the manifest main
branch.
* In order to correct this approach, we define a function that searches
  for the INTEGRATION variable in each project and get the name of
the branch whose changes are integrated into the manifest main branch. If
more than one branch integrates into the manifest one, all of them are
considered in the search for MRs to be inserted in the changelog.
* Include BSP repositories and new meta-layers in CHANGELOG_PROJECTS
  variable

* This commit fixes the build not working for C72nl device due to bug
in logic of code creating gitlab-ci configuration file for each machine.

* The notify job needs to pull the artifacts from all previous jobs and
as the number of boards increase the timeout needs to increase
accordingly.

* Instead of inserting the "weekly" string in the artifacts name, which is
  already defined in the Azure path, we insert the short SHA for not
tagged version of Edgehog.
* Remove TAG_NAME variable from "latest" tagged artifacts

* Instead of setting the kernel version by variable, the kernel main
version is derived from the PREFERRED_VERSION of virtual/kernel used
by Yocto using bitbake commands.
* The following algorithm does not actually apply on the 'c31' and
'tanaro' boards, for which a different handling is applied.

* Since for Intel boards the PROCESSOR and BOARD variable values
  coincides, it is necessary to handle this case and remove one of the
two variables from the artifact name.

* From now on, the compiled image for all Intel CPU-based SECO boards
will be unique and not separate for different processor generations/flavours.
* Bump of the kernel version for all Intel architectures to rel. 6.1.
* Set KERNEL variable separately for each board and avoid the
  override of the value set in the generic yocto variables.

* Insert 'imx8' string in the path instead of the specific processor
  type.

* Since custom projects may require to insert some flags in the
  'conf/local.conf' file (e.g. software products commercial licences)
we define the handling of the CUSTOM_CONF variable to contain the lines
that need to be inserted in the file.
* Update documentation accordingly.

In the upgrade from GitLab release 15.4.2 to GitLab release 16.8.2 this
syntax fix is necessary in order for all the integration pipelines to start
correctly

* This modification is necessary in order to use specific runners
  installed on a server dedicated to Edgehog build

* Add E09 board based on Rockchip rk3568 processor
* Add Alder Lake for x86 Intel processors
* Include specific processor type on PROCESSOR variable for imx8 based
  boards

* The build is always triggered via a parent pipeline in this version
of the CI/CD so it was necessary to fix the condition.

* This is a first implementation of automatic testing of Things distro
using SECO LAVA lab.
* The test is directed to 4 device types, one for each main architecture
(imx6, imx8, Rockchip, Intel).

The variable needs to be added as a project variable in order to specify
the manifest file on which the meta-layer needs to be integrated.

The MACHINE parameter is fundamental in order to match the path of the
built artifacts gin GitLab CI

* In a first implementation of the build logic, the downloads and
sstate-cache were supposed to be used only on sheduled and MR builds.
However, as the number of supported boards increase, there is more necessity of
CPU and time to get all Yocto images built when a tag is performed. For
this reason we decide to remove the differentiation at least as long as
the build server is not upgraded.

* The report creation included an extra string on the link to the
artifacts that was not really present and gave rise to not working URLs.

In the previous implementation the deploy-ci job was looking only for
projects with the INTEGRATION project variable explicitly referring to
the manifest repository. With this fix, the script will allow searching
also forprojects with the reference to the meta-layer inside the
INTEGRATION variable, thus allowing to integrate CI also for 'bsp' group
projects.

Every time a BSP related MR is merged, the SRCREV.conf file in the
corresponding meta-layer is updated and all other integration MRs in
that meta-layer can no longer be merged due to conflicts. For this
reason we add this steps every time a BSP related MR is merged:
* Search for all open MRs in the same BSP group of the project on which
the MR occurred.
* Retrigger the pipelines for all these MRs, that in turn updates the
integration branches in the meta-layer.
* All the integration MRs in the meta-layer are now mergeable so that if
two or more MRs are merged (tipically U-Boot and Kernel MRs are merged
almost at the same time) no conflict are expected to occur.
* Moreover, this procedure allows to have an integration MR in the
meta-layer always updated with the latest BSP version in the main
branch.

To make this work we also need to change the retrigger job, avoiding the
possibility to run 'check' jobs that are already running and that would
throw an error.

* The timeout in that jobs need to scale up as the number of boards and
thus build jobs increases.
* Increase timeout also in .infrastructure generic job for CI tasks
since sometimes it failed because it took too much to clone/fetch the
repository.

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