* The Raspberry Pi 4 machine only supports U-Boot in Edgehog Things distro,
for this reason we introduce a check on the presence of U-Boot files and
eventually not deploy the package in case no files are found.
* At build time, we only check the number of U-Boot artifacts and give a
  warning if they are less than expected.

* Add support to build on BSP integration branches
* Add dedicated sstate-cache folder support
* Add repositories support in scripts and configuration files for
  changelog creation

* The integration branch name when a new MR is created actually contains
  the repository name, while the script that is performing the merging
of the branch was using the recipe name. Aligning the behaviour of the
two scripts.
* Handle GitLab exception when no MR pipeline is created.
* Insert Mediatek handling in pipeline retriggering function.

* Use a dedicated token with higher restrictions to be used when
  triggering LAVA tests
* Jira bug reference: SW-2172

* Sometimes the error ‘422: Branch cannot be merged’ has been noted
in cases where the automation fails to rebase (despite no conflicts)
 and then automatically merge an MR.
* This commit circumvents the problem by trying to rebase
when such an error occurs and then trying again to merge.
* Jira bug reference: SW-1555

* The fix allows to perform build also on Edgehog Things images

* Cleanup of the code part for compiling the different machines for
Intel (x86) CPU-based boards

In order to handle the scenarios where bitbake needs to compile an
image different from the standard ones we introduce the possibility to
have a custom DISTRO variable value. However, the variable shall follow
the following convention:

* The first part of the string shall indicate the standard Edgehog OS
  distro, i.e. 'things' or 'embedded' as of now
* The second part of the string shall be the custom Edgehog OS image
  distro with at maximum a '-' as a separator, e.g. 'custom-image'
* The two parts of the string shall be separated by a '-'

An example could be 'embedded-custom-image'.

* The 'apollolake' machine is no longer used since a single Intel image
  is released

* This commit removee the read-only SAS token from the name of the artifact

* Update preferred kernel version to 5.10 for C31
* Add comment to make the kernel version forcing reason for some of the
  boards more explanatory

Since now, the integration branch name created by a MR on the BSP
into the layer was formed by the BB_RECIPE_NAME followed by the name
of merge request source branch. Changing the BB_RECIPE_NAME with the
CI_PROJECT_PATH variable to fix a bug in the build process when
integration is performed and the integration branch is not found and
also for consistency reasons.

Since now, when searching for a recipe name, if the line in the SRCREV.conf
file was matched, a break occurred, and all the lines with the same commit SHA
of that line were updated. This could be the case of the SRCREV.conf file
for meta-seco-rk layer where there need to be two recipes (one for u-boot
 and one for fw-sysdata) pointing to the same commit SHA.
In that case, if both recipes had the same commit SHA, the
script could handle it and update both lines. However, if a misalignment
occured by any chance, the script could not handle it. For this reason
we search for all occurrencies of the same recipe name in the
SRCREV.conf and update separately each occurrency.

* 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.