From d7589278f32d87e3ebbeb01dbd2bceffa2c37276 Mon Sep 17 00:00:00 2001
From: Lorenzo Pagliai <lorenzo.pagliai@seco.com>
Date: Mon, 21 Nov 2022 15:13:26 +0100
Subject: [PATCH] Porting of CI/CD scripts for compatib. with yocto_ng

* 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
---
 .gitlab-ci.yml                                |  77 +++---
 README.md                                     |  37 ++-
 common.yml                                    |   6 +-
 docs/automatic-manifest-integration.md        |  58 ++---
 docs/gitlab-ci-deployment.md                  |   2 +-
 docs/manifest-pipeline.md                     |  51 +++-
 manifest-integration.yml                      |   4 +-
 manifest-pipeline-yocto.yml                   |  24 +-
 .../manifest-integration_seco_ne.yml          |   0
 .../manifest-pipeline-yocto-original.yml      |   0
 prova.txt                                     |   4 -
 test_manifest.yml                             | 224 ------------------
 testing.yml                                   |  14 --
 13 files changed, 144 insertions(+), 357 deletions(-)
 rename manifest-integration_GF.yml => old/manifest-integration_seco_ne.yml (100%)
 rename manifest-pipeline-yocto-original.yml => old/manifest-pipeline-yocto-original.yml (100%)
 delete mode 100644 prova.txt
 delete mode 100644 test_manifest.yml
 delete mode 100644 testing.yml

diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 890d21a..775ce7e 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -3,16 +3,14 @@
 # Global
 # ---------------------------------------------------------------------------------------
 
-#Testing 
-
 variables:
-  CI_IMAGES_BASEPATH: "git.seco.com:5050/edgehog/yocto_ng/"
-  CI_IMAGES_PATH: ${CI_IMAGES_BASEPATH}/seco-manifest/python3.9
+  # CI_IMAGES_BASEPATH: Environment variable configure in gitlab
+  CI_IMAGES_PATH: ${CI_IMAGES_BASEPATH}/ci-images
   CI_IMAGES_REV: latest
-  CI_IMAGE_PYTHON: "git.seco.com:5050/edgehog/yocto_ng/seco-manifest/python3.9:${CI_IMAGES_REV}"
-  CI_IMAGE_YOCTO: "${CI_IMAGES_PATH}/yocto-build/ubuntu-20.04:${CI_IMAGES_REVISION}"
+  CI_IMAGE_PYTHON: "${CI_IMAGES_PATH}/infrastructure/python3.9:${CI_IMAGES_REV}"
+  CI_IMAGE_YOCTO: "secodocker/edgehog-builder:${CI_IMAGES_REV}"
 
-image: "${CI_IMAGE_PYTHON}" #secodocker/manifest-test:vtemp #
+image: "${CI_IMAGE_PYTHON}"
 
 default:
   tags:
@@ -72,7 +70,6 @@ executable:
   stage: integrate
   rules:
     - if: $CI_MERGE_REQUEST_IID
-      #when: manual
       allow_failure: true
   variables:
     MERGE: ""
@@ -115,15 +112,15 @@ executable:
 
 # Jobs
 
-#integrate-ci-test:primary:
-#  extends: .integrate-ci-test
-#  variables:
-#    MANIFEST_BRANCH: primary
+integrate-ci-test:primary:
+  extends: .integrate-ci-test
+  variables:
+    MANIFEST_BRANCH: primary
 
-#integrate-ci-test:secondary:
-#  extends: .integrate-ci-test
-#  variables:
-#    MANIFEST_BRANCH: secondary
+integrate-ci-test:secondary:
+  extends: .integrate-ci-test
+  variables:
+    MANIFEST_BRANCH: secondary
 
 #integrate-yocto:dunfell:
 #  extends: .integrate-yocto
@@ -148,33 +145,33 @@ integrate-yocto:kirkstone:
     - if: $CI_MERGE_REQUEST_LABELS =~ /skip build/
       when: never
 
-#.build-ci-test:
-#  extends: .build
-#  trigger:
-#    project: seco-ne/yocto/infrastructure/ci-test/minimal-manifest
-#    branch: "integrate/${CI_PROJECT_NAME}/${CI_COMMIT_REF_NAME}/into/${MANIFEST_BRANCH}"
-#    strategy: depend
+.build-ci-test:
+  extends: .build
+  trigger:
+    project: yocto_ng/infrastructure/ci-test/minimal-manifest
+    branch: "integrate/${CI_PROJECT_NAME}/${CI_COMMIT_REF_NAME}/into/${MANIFEST_BRANCH}"
+    strategy: depend
 
 .build-yocto:
   extends: .build
   trigger:
-    project: edgehog/yocto_ng/seco-manifest
+    project: yocto_ng/seco-manifest
     branch: "integrate/${CI_PROJECT_NAME}/${CI_COMMIT_REF_NAME}/into/${MANIFEST_BRANCH}"
     strategy: depend
 
 # Jobs
 
-#build-ci-test:primary:
-#  extends: .build-ci-test
-#  needs: ["integrate-ci-test:primary"]
-#  variables:
-#    MANIFEST_BRANCH: primary
+build-ci-test:primary:
+  extends: .build-ci-test
+  needs: ["integrate-ci-test:primary"]
+  variables:
+    MANIFEST_BRANCH: primary
 
-#build-ci-test:secondary:
-#  extends: .build-ci-test
-#  needs: ["integrate-ci-test:secondary"]
-#  variables:
-#    MANIFEST_BRANCH: secondary
+build-ci-test:secondary:
+  extends: .build-ci-test
+  needs: ["integrate-ci-test:secondary"]
+  variables:
+    MANIFEST_BRANCH: secondary
 
 #build-yocto:dunfell:
 #  extends: .build-yocto
@@ -201,16 +198,16 @@ build-yocto:kirkstone:
   variables:
     MERGE: --merge --project=${CI_PROJECT_PATH} --branch=${CI_COMMIT_REF_NAME}
 
-#merge-ci-test:
-#  extends:
-#    - .integrate-ci-test
-#    - .merge
-#  variables:
-#    MANIFEST_BRANCH: primary,secondary
+merge-ci-test:
+  extends:
+    - .integrate-ci-test
+    - .merge
+  variables:
+    MANIFEST_BRANCH: primary,secondary
 
 merge-yocto:
   extends:
     - .integrate-yocto
     - .merge
   variables:
-    MANIFEST_BRANCH: kirkstone/develop #dunfell,
+    MANIFEST_BRANCH: kirkstone/develop
diff --git a/README.md b/README.md
index 158955d..a6378d6 100644
--- a/README.md
+++ b/README.md
@@ -10,26 +10,23 @@ be included into all relevant Yocto repositories as a [git submodule][1].
 
 
 <!----------------------------------------------------------------------------->
-## The GitBot user
+## The EdgeBot token
 <!----------------------------------------------------------------------------->
 
-Most scripts inside this repository need a [personal GitLab access token][2] of
+Most scripts inside this repository need a [group GitLab access token][2] of
 a user with access to all relevant repositories (manifest and all contained
 projects) in order to work correctly.
-We have created the @gitbot user for this task. The login credentials for it are
-stored in our [KeePass][3] safe. These should not be needed, though, as the user
-is member of the [`seco-ne`][4] group and thus already has access to all group
-projects. However, everyone can add the user as a member to every project he has
-access to, if needed.
+We have created the **EdgeBot** group access token for this task. The token has
+maintainer permissions in the [`yocto_ng` group][3] and has all of the token 
+permissions enabled (read/write API access, read/write registry access, etc.).
 
-The personal access token of the @gitbot is provided via the CI environment
-variable `GITBOT_TOKEN` for all projects in the `seco-ne` group (set in the
-[group's CI/CD settings][5] under "Variables").
+The group access token value is provided via the CI environment variable
+`GITBOT_TOKEN` for all projects in the `yocto_ng` group (set in the
+[group's CI/CD settings][4] under "Variables").
 
-[2]: https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html
-[3]: https://keepass.info
-[4]: https://git.seco.com/seco-ne
-[5]: https://git.seco.com/groups/seco-ne/yocto/-/settings/ci_cd
+[2]: https://docs.gitlab.com/ee/user/group/settings/group_access_tokens.html
+[3]: https://git.seco.com/yocto_ng
+[4]: https://git.seco.com/groups/yocto_ng/-/settings/ci_cd
 
 
 <!----------------------------------------------------------------------------->
@@ -38,9 +35,9 @@ variable `GITBOT_TOKEN` for all projects in the `seco-ne` group (set in the
 
 See this chapter for information on how the automatic integration process works:
 
-â–¶ [Automatic manifest integration][6]
+â–¶ [Automatic manifest integration][5]
 
-[6]: docs/automatic-manifest-integration.md
+[5]: docs/automatic-manifest-integration.md
 
 
 <!----------------------------------------------------------------------------->
@@ -50,9 +47,9 @@ See this chapter for information on how the automatic integration process works:
 See this chapter for information on how to deploy changes in the `gitlab-ci`
 repository to all repositories that are using it.
 
-â–¶ [gitlab-ci Deployment][7]
+â–¶ [gitlab-ci Deployment][6]
 
-[7]: docs/gitlab-ci-deployment.md
+[6]: docs/gitlab-ci-deployment.md
 
 <!----------------------------------------------------------------------------->
 # Manifest pipeline
@@ -61,6 +58,6 @@ repository to all repositories that are using it.
 See this chapter for the pipeline runnning in the manifest repository to build
 the images.
 
-â–¶ [manifest Pipeline][8]
+â–¶ [manifest Pipeline][7]
 
-[8]: docs/manifest-pipeline.md
+[7]: docs/manifest-pipeline.md
diff --git a/common.yml b/common.yml
index 04cb7ff..b35c9ef 100644
--- a/common.yml
+++ b/common.yml
@@ -5,9 +5,9 @@
 variables:
   # CI_IMAGES_BASEPATH: Environment variable configure in gitlab
   CI_IMAGES_PATH: ${CI_IMAGES_BASEPATH}/ci-images
-  CI_IMAGES_REV: test
-  CI_IMAGE_PYTHON: "git.seco.com:5050/edgehog/yocto_ng/seco-base:${CI_IMAGES_REV}"
-  CI_IMAGE_YOCTO: "secodocker/edgehog-builder:latest"
+  CI_IMAGES_REV: latest
+  CI_IMAGE_PYTHON: "${CI_IMAGES_PATH}/infrastructure/python3.9:${CI_IMAGES_REV}"
+  CI_IMAGE_YOCTO: "secodocker/edgehog-builder:${CI_IMAGES_REV}"
   # Include git submodules
   GIT_SUBMODULE_STRATEGY: recursive
   # Reduced depth as checkout of larger projects (like the kernel)
diff --git a/docs/automatic-manifest-integration.md b/docs/automatic-manifest-integration.md
index c018c63..b7e7fcf 100644
--- a/docs/automatic-manifest-integration.md
+++ b/docs/automatic-manifest-integration.md
@@ -3,10 +3,16 @@
 <!----------------------------------------------------------------------------->
 
 **Contents:**
-- [Defined source code state](#defined-source-code-state)
-- [Integrating project changes](#integrating-project-changes)
-- [Merging project changes](#merging-project-changes)
-- [Adding a new project to SRCREV.conf](#adding-a-new-project-to-srcrevconf)
+- [Automatic manifest integration](#automatic-manifest-integration)
+  - [Defined source code state](#defined-source-code-state)
+    - [Manifest](#manifest)
+    - [External source repositories used by BitBake (Currently not used)](#external-source-repositories-used-by-bitbake-currently-not-used)
+  - [Integrating project changes](#integrating-project-changes)
+      - [Skipping the build](#skipping-the-build)
+  - [Merging project changes](#merging-project-changes)
+  - [Adding a new project to SRCREV.conf](#adding-a-new-project-to-srcrevconf)
+      - [Source code](#source-code)
+      - [Repository settings](#repository-settings)
 
 
 <!----------------------------------------------------------------------------->
@@ -16,7 +22,7 @@
 ### Manifest
 
 Our [Yocto manifest][1] contains a list of projects which are used to build our
-Yocto distribution. A simplified version of the manifest file [`default.xml`][2]
+Yocto distribution. A simplified version of a manifest file [`default.xml`][2]
 (here containing only two projects) would look something like this:
 
 ```xml
@@ -47,7 +53,7 @@ tool will clone the source code to, and a fixed git **revision**. We do not use
 a branch name here in order to have a defined, taggable manifest state at all
 times.
 
-### External source repositories used by BitBake
+### External source repositories used by BitBake (Currently not used)
 
 Some bitbake recipes are set to `SRCREV = "${AUTOREV}"`. To enable reproducible
 builds, the revision for these recipes is written to the `SRCREV.conf` file.
@@ -62,8 +68,8 @@ SRCREV_pn-xconfig = "0fc1ea45b55e729d551bb7d40dd25fbde02ee1b6"
 Each project is listed with its bitbake **recipe name** after `SRCREV_PN-` and
 the fixed git **revision**.
 
-[1]: https://git.seco.com/seco-ne/yocto/manifest
-[2]: https://git.seco.com/seco-ne/yocto/manifest/-/blob/dunfell/default.xml
+[1]: https://git.seco.com/yocto_ng/seco-manifest
+[2]: https://git.seco.com/yocto_ng/seco-manifest/-/blob/kirkstone/develop/distro/seco-distro.xml
 [3]: https://gerrit.googlesource.com/git-repo
 
 
@@ -96,19 +102,20 @@ The pipeline consists of three jobs:
 3. **Check**
 
    Check if the integration branch is up to date with the current manifest
-   master (see ["Retrigger" job below][5] for why this is necessary).
+   master (see ["Retrigger" job below][6] for why this is necessary).
 
 See the following diagram for a visualization of this process:
 
 ![Create layer merge request](create-layer-mr.svg)
 
-Browse existing project merge requests (e.g. [here][6]) for real world examples
-of this pipeline.
-
 The above workflow makes project changes **buildable** and **testable** in the
-full manifest environment **before merging them**. Actually we even prevent the
-project merge requests from being merged unless the pipeline has run
-successfully.
+full manifest environment **before merging them**. Actually, the user could even 
+[prevent the project merge requests from being merged unless the pipeline has run
+successfully][5].
+
+[4]: https://docs.gitlab.com/ee/ci/pipelines/multi_project_pipelines.html
+[5]: https://docs.gitlab.com/ee/user/project/merge_requests/merge_when_pipeline_succeeds.html
+[6]: #merging-project-changes
 
 #### Skipping the build
 
@@ -119,11 +126,6 @@ on its creation. The `build` and `check` stages of the pipeline are left out
 then, and the merge request can be merged immediately after the `integrate`
 stage has completed.
 
-[4]: https://docs.gitlab.com/ee/ci/pipelines/multi_project_pipelines.html
-[5]: #merging-project-changes
-[6]: https://git.seco.com/seco-ne/yocto/layers/meta-seconorth-distro/-/merge_requests/321
-
-
 <!----------------------------------------------------------------------------->
 ## Merging project changes
 <!----------------------------------------------------------------------------->
@@ -167,16 +169,14 @@ See the following diagram for a visualization of this process:
 
 ![Merge layer merge request](merge-layer-mr.svg)
 
-Browse existing manifest merge requests (e.g. [here][7]) for real world examples
-of this pipeline.
-
-[7]: https://git.seco.com/seco-ne/yocto/manifest/-/merge_requests/545
-
-
 <!----------------------------------------------------------------------------->
 ## Adding a new project to SRCREV.conf
 <!----------------------------------------------------------------------------->
 
+**NOTE**: Currently the `SRCREV.conf` file is not used but is created in the 
+manifest repository for automation purposes. In any case, the steps below shall
+be kept in mind to properly configure CI/CD on the yocto projects/manifest.
+
 This workflow adds a gitlab pipeline to a project which automatically updates
 the git revision in the `SRCREV.conf` file on project changes.
 
@@ -184,10 +184,10 @@ the git revision in the `SRCREV.conf` file on project changes.
 
 1. Add the gitlab-ci repo as submodule to the project by using the correct
    relative path:\
-   `git submodule add ../../yocto/infrastructure/gitlab-ci .gitlab-ci`
+   `git submodule add ../../../infrastructure/gitlab-ci .gitlab-ci`
 
 2. Add an approriate `.gitlab-ci.yml` file. For example, copy it from the
-   repository [egalxi2c][8]. Modify the following variables in the file:
+   repository [meta-seco-edgehog][8]. Modify the following variables in the file:
    * `BB_RECIPE_NAME`: Set the name of the bitbake recipe
 
 3. Create a corresponding entry in the `SRCREV.conf` file of the manifest repo:\
@@ -207,4 +207,4 @@ the git revision in the `SRCREV.conf` file on project changes.
 3. Check that the default branch is protected and that *Maintainers + 
    Developers* are allowed to merge (Repository -> Protected branches)
 
-[8]: https://gitlab.com/seco-ne/kernel/modules/egalaxi2c
+[8]: https://git.seco.com/yocto_ng/layers/seco/meta-seco-edgehog
diff --git a/docs/gitlab-ci-deployment.md b/docs/gitlab-ci-deployment.md
index 587e05d..6a4e2bf 100644
--- a/docs/gitlab-ci-deployment.md
+++ b/docs/gitlab-ci-deployment.md
@@ -17,7 +17,7 @@ As this repo contains all the CI code, some extra care is needed in order not to
 break the whole thing. To allow testing the CI before everything is merged into the Yocto pipeline, a sandbox environment in the form of a set of test projects is
 available in the [ci-test group][1].
 
-[1]: https://git.seco.com/seco-ne/yocto/infrastructure/ci-test
+[1]: https://git.seco.com/yocto_ng/infrastructure/ci-test
 
 
 <!----------------------------------------------------------------------------->
diff --git a/docs/manifest-pipeline.md b/docs/manifest-pipeline.md
index 27ceb66..7a81d80 100644
--- a/docs/manifest-pipeline.md
+++ b/docs/manifest-pipeline.md
@@ -4,25 +4,66 @@
 
 The pipeline running in the manifest repository is the one that does the real
 work, like building images, generating docs and deploying image to download
-servers and triggering tests in the lava test rack.
+servers and triggering tests in LAVA (TO DO). The pipeline running in the manifest
+repository is described in the `manifest-pipeline-yocto.yml` [file][1].
+
+[1]:https://git.seco.com/yocto_ng/infrastructure/gitlab-ci/-/blob/master/manifest-pipeline-yocto.yml
 
 <!----------------------------------------------------------------------------->
 ## Triggers
 <!----------------------------------------------------------------------------->
 
-TODO
+The build in the manifest repository is currently triggered both on a weekly 
+basis (on Friday evenings) on the `MASTER_BRANCH` branch and asynchronously 
+whenever a merge request is opened on a project or on the repository containing
+CI/CD scripts. Eventually the asynchronous build can be skipped in case the
+`skip build` label is specified when opening the merge request. 
+
+The `deploy` and `notify` stage job are currently triggered only on scheduled 
+pipeline.
 
 <!----------------------------------------------------------------------------->
 ## Build jobs
 <!----------------------------------------------------------------------------->
 
-TODO
+The build stage generic description is present in the `manifest-pipeline-yocto.yml`
+file while the variables which differs from board to board are imported from the 
+files in the `boards` [folder][2]. To include another board within the compiled 
+one it will then be necessary to include at the beginning of the 
+`manifest-pipeline-yocto.yml` file the corresponding board configuration file.
+
+The build jobs either compile the Egdehog image and the bundle.
+
+[2]:https://git.seco.com/yocto_ng/infrastructure/gitlab-ci/-/tree/master/boards
 
 <!----------------------------------------------------------------------------->
 ## Deploy and upload jobs
 <!----------------------------------------------------------------------------->
 
-TODO
+The artifacts from the previous stage are made available to the `deploy` stage 
+which allows to rename, assign a tag and push to our Azure blob storage containers
+all the relevant artifacts from the `build` stage, i.e. U-Boot, Kernel, `.wic`
+image, etc. The upload to Azure simply takes advantage of the three [variables
+defined at group level][3]:
+
+* `AZURE_STORAGE_ACCOUNT`: the name of the blob storage account software artifacts shall be uploaded to.
+* `AZURE_CONTAINER_NAME`: the name of the blob storage container used to store software artifacts.
+* `AZURE_STORAGE_SAS_TOKEN`: the [SAS token][4] associated to the corresponding Azure container.
+
+[3]:https://git.seco.com/groups/yocto_ng/-/settings/ci_cd
+[4]:https://learn.microsoft.com/it-it/azure/cognitive-services/translator/document-translation/create-sas-tokens?tabs=Containers
+
+<!----------------------------------------------------------------------------->
+## Notify Job
+<!----------------------------------------------------------------------------->
+
+Once all jobs associated to the `build` and `deploy` stages have finished, the 
+`notify` stage allows to collect the results from all previous jobs (and the link 
+to the artifacts) and to send them to the dedicated channel in Microsoft Teams 
+Edgehog group. The notification is allowed by using an [Incoming WebHook][5], 
+saved as a [group variable][3] 
+
+[5]:https://learn.microsoft.com/en-us/microsoftteams/platform/webhooks-and-connectors/how-to/add-incoming-webhook
 
 <!----------------------------------------------------------------------------->
 ## Test jobs
@@ -31,7 +72,7 @@ TODO
 TODO
 
 <!----------------------------------------------------------------------------->
-## Job generation, parent child jobs
+## Job generation, parent child jobs (NOT USED)
 <!----------------------------------------------------------------------------->
 
 As we support images for multiple machines/architectures we are building a lot
diff --git a/manifest-integration.yml b/manifest-integration.yml
index 0526b9b..605a2c3 100644
--- a/manifest-integration.yml
+++ b/manifest-integration.yml
@@ -20,11 +20,9 @@ variables:
   # has to specify it in its own gitlab-ci.yml file.
   # The BB_RECIPE_NAME is passed to the python scripts below anyway, but not
   # used for projects referenced in the manifest file.
-  #GITLAB_CI_REVISION: 80380e9065c04e7983fa36d451a9a62d96e5addb
   # FIXME: This is only necessary due to the following GitLab limitation:
   # https://gitlab.com/gitlab-org/gitlab/-/issues/209904
   # As soon as this gets fixed upstream, the hard-coded branch name should be removed.
-  #MASTER_BRANCH: kirkstone/develop
   MANIFEST_PROJECT: seco-manifest
   MASTER_BRANCH_MANIFEST: kirkstone/develop
   BB_RECIPE_NAME: none
@@ -124,7 +122,7 @@ build:
   #script:
   #  - echo "Building"
   trigger:
-    project: edgehog/yocto_ng/seco-manifest
+    project: yocto_ng/seco-manifest
     branch: "integrate/${CI_PROJECT_NAME}/${CI_COMMIT_REF_NAME}/into/${MASTER_BRANCH_MANIFEST}"
     strategy: depend
 # 
diff --git a/manifest-pipeline-yocto.yml b/manifest-pipeline-yocto.yml
index 30cb495..34aabee 100644
--- a/manifest-pipeline-yocto.yml
+++ b/manifest-pipeline-yocto.yml
@@ -7,22 +7,23 @@ include:
     - local: common.yml
     - local: boards/.a62.yml
     - local: boards/.c20.yml
-
+    - local: boards/.c31.yml
+    
 variables:
   # The id of the gitlab project used in the rules section to not run pipelines in
   # forked projects. Using variable here, to allow override in other projects including
   # this file.
-  MANIFEST_PROJECT_ID: 2307
+  #MANIFEST_PROJECT_ID: 2307
 
   # In the manifest, the remotes are specified by an identifier. This is used to find
   # out included projects for the retrigger job. In custom manifests, the remote may be
   # named differently, so we need a variable that may be overriden.
-  CI_PARAM_SECO_REMOTE: edgehog
+  CI_PARAM_SECO_REMOTE: yocto_ng
 
   # GitLab group to search for projects to retrigger
   RETRIGGER_GROUP: ${CI_PROJECT_ROOT_NAMESPACE}
 
-  BUILD_TIMEOUT: 4h
+  BUILD_TIMEOUT: 6h
 
   # This is the jinja2 template file used to generate the build jobs
   #BUILD_JOBS_TEMPLATE: build-jobs-yocto.yml.jinja2
@@ -144,7 +145,7 @@ retrigger:
   stage: build
   timeout: !reference [variables, BUILD_TIMEOUT]
   image: 
-    name: secodocker/edgehog-builder:v1.1
+    name: ${CI_IMAGE_YOCTO}
     entrypoint: [""]
   cache: {}
   retry : 2
@@ -170,12 +171,11 @@ retrigger:
       - export EULA=1
       - |
         su secous -c "
-        #$CI_REPOSITORY_URL
-        repo init -u git@git.seco.com:yocto_ng/seco-manifest.git -b kirkstone/develop; 
+        repo init -u ${CI_REPOSITORY_URL} -b kirkstone/develop; 
         repo sync -j$(nproc) --fetch-submodules;
-        . ./seco-setup.sh -d $DEFCONFIG_FILE;
+        . ./seco-setup.sh -d ${DEFCONFIG_FILE};
         . ./seco-setup.sh -c;
-        time bitbake $RECIPE_NAME;
+        time bitbake ${RECIPE_NAME};
         time bitbake seco-bundle-edgehog;
         "
       - ls -la
@@ -220,9 +220,7 @@ retrigger:
  stage: deploy
  cache: {}
  retry : 2
- timeout: 4 hours
- tags:
-   - azure_deploy
+ timeout: 20 m
  rules:
     # Trigger deploy jobs only on a schedule basis (for weekly release)
     - if: $CI_PIPELINE_SOURCE == "schedule" 
@@ -448,8 +446,6 @@ notify:
   image: 
     name: mcr.microsoft.com/azure-cli
     entrypoint: [""]
-  tags:
-    - send_notify
   allow_failure: true
   rules:
     # Trigger deploy jobs only on a schedule basis (for weekly release)
diff --git a/manifest-integration_GF.yml b/old/manifest-integration_seco_ne.yml
similarity index 100%
rename from manifest-integration_GF.yml
rename to old/manifest-integration_seco_ne.yml
diff --git a/manifest-pipeline-yocto-original.yml b/old/manifest-pipeline-yocto-original.yml
similarity index 100%
rename from manifest-pipeline-yocto-original.yml
rename to old/manifest-pipeline-yocto-original.yml
diff --git a/prova.txt b/prova.txt
deleted file mode 100644
index 8afd2a5..0000000
--- a/prova.txt
+++ /dev/null
@@ -1,4 +0,0 @@
-testing
-testing
-testing
-testing
diff --git a/test_manifest.yml b/test_manifest.yml
deleted file mode 100644
index 0128626..0000000
--- a/test_manifest.yml
+++ /dev/null
@@ -1,224 +0,0 @@
----
-# --------------------------------------------------------------------------------------
-# Global
-# --------------------------------------------------------------------------------------
-stages:
-  - infrastructure
-  - integrate
-  - merge
-  - build
-  - check
-
-variables:
-  MANIFEST_FILE: "distro/seco-distro.xml"
-  # The BB_RECIPE_NAME is used for projects referenced in the SRCREV file
-  # to match the repository and the bitbake recipe name.
-  # We set it here to none, as every project needing it
-  # has to specify it in its own gitlab-ci.yml file.
-  # The BB_RECIPE_NAME is passed to the python scripts below anyway, but not
-  # used for projects referenced in the manifest file.
-  #GITLAB_CI_REVISION: 80380e9065c04e7983fa36d451a9a62d96e5addb
-  # FIXME: This is only necessary due to the following GitLab limitation:
-  # https://gitlab.com/gitlab-org/gitlab/-/issues/209904
-  # As soon as this gets fixed upstream, the hard-coded branch name should be removed.
-  #MASTER_BRANCH: kirkstone/develop
-  MANIFEST_PROJECT: seco-manifest
-  MASTER_BRANCH_MANIFEST: kirkstone/develop
-  MASTER_BRANCH_PROJECT: main
-  BB_RECIPE_NAME: none
-
-  CI_IMAGES_PATH: ${CI_IMAGES_BASEPATH}/ci-images
-  CI_IMAGES_REV: 44965ccdd847f1e077670f49d546047f8ad0110c
-  CI_IMAGE_PYTHON: "${CI_IMAGES_PATH}/python/3.9:${CI_IMAGES_REV}"
-  CI_IMAGE_YOCTO: "${CI_IMAGES_PATH}/yocto-build/ubuntu-20.04:${CI_IMAGES_REV}"
-  # Include git submodules
-  #GIT_SUBMODULE_STRATEGY: recursive
-  # Reduced depth as checkout of larger projects (like the kernel)
-  # may take too long
-  GIT_DEPTH: 1
-
-  DEPLOYPATH_TEST: "/artifacts/${CI_JOB_ID}/"
-  GITLAB_SERVER: "${CI_SERVER_HOST}:${CI_SERVER_SSH_PORT}"
-  GIT_BASE_URL: "ssh://git@${GITLAB_SERVER}/${CI_PROJECT_ROOT_NAMESPACE}"
-  TESTS_GIT_URL: "${GIT_BASE_URL}/yocto/tests.git"
-
-.infrastructure:
-  stage: infrastructure
-  tags:
-    - infrastructure
-  timeout: 10m
-  image: secodocker/manifest-test:vtemp #"${CI_IMAGE_PYTHON}"
-  needs: []
-  variables:
-    # Include git submodules
-    #GIT_SUBMODULE_STRATEGY: recursive
-    CI_COMMIT_SOURCE: ${CI_COMMIT_SHA}
-
-# workflow:
-#   rules:
-#     # Explicitly allow externally triggered pipelines in every case
-#     - if: $CI_PIPELINE_SOURCE == "pipeline" || $CI_PIPELINE_SOURCE == "api"
-#     # Do not run pipelines on forked projects.
-#     # The pipelines would not work anyway because of the users permissions.
-#     # There are two cases catched here:
-#     # 1. The project is forked into someones gitlab namespace and a MR to
-#     #    include a change into this forked project is created. In this case
-#     #    is the CI_PROJECT_ROOT_NAMESPACE not seco-ne but the
-#     #    namespace the fork lives in.
-#     # 2. The MR from the forked project is created to merge the change into this
-#     #    the project in the seco-ne namespace (customer sending
-#     #    change to us). Here the the IDs used below differ.
-#     #
-#     - if: $CI_PROJECT_ROOT_NAMESPACE == "edgehog"
-#         && $CI_MERGE_REQUEST_SOURCE_PROJECT_ID == $CI_MERGE_REQUEST_PROJECT_ID
-
-# --------------------------------------------------------------------------------------
-# Stage: infrastructure
-# --------------------------------------------------------------------------------------
-integrate:
-  extends: .infrastructure
-  rules:
-    # Do not integration pipeline for merge requests for integrate/gitlab-ci/ branches
-    # The integration is done from the pipeline in gitlab-ci already
-    - if: $CI_COMMIT_REF_NAME =~ /^integrate\/gitlab-ci\/.*/
-      when: never
-    # We have to make sure that the pipeline runs for the current manifest
-    # master at the time a merge request is created. Otherwise we cannot
-    # guarantee a green master after merging.
-    #- if: $CI_PIPELINE_SOURCE == "merge_request_event"
-    - if: $CI_MERGE_REQUEST_IID
-    - if: $CI_PIPELINE_SOURCE == "schedule"
-      when: always
-    # Explicitly allow externally triggered pipelines in every case
-    - if: $CI_PIPELINE_SOURCE == "pipeline" || $CI_PIPELINE_SOURCE == "api"
-  cache:
-    policy: push
-  script:
-    - echo "CI_PROJECT_DIR is defined as ${CI_PROJECT_DIR}"
-    - echo "CI_PROJECT_PATH is defined as ${CI_PROJECT_PATH}"
-    - echo "CI_SERVER_URL is defined as ${CI_SERVER_URL}"
-    - echo "CI_MERGE_REQUEST_IID is defined as ${CI_MERGE_REQUEST_IID}"
-    - cd ${CI_PROJECT_DIR}
-    - if [ -n "${CI_MERGE_REQUEST_IID}" ];then
-        MERGE_REQUEST="${CI_MERGE_REQUEST_IID}";
-      else
-        MERGE_REQUEST="${CI_OPEN_MERGE_REQUESTS%%,*}";
-      fi
-    - python3 scripts/integrate_into_manifest.py
-        --gitlab-url=${CI_SERVER_URL}
-        --token=${GITBOT_TOKEN}
-        --manifest-project=${MANIFEST_PROJECT}
-        --manifest-file=${MANIFEST_FILE}
-        --integration-base=${MASTER_BRANCH_MANIFEST}
-        --project=${CI_PROJECT_PATH}
-        --merge-request=${MERGE_REQUEST}
-        --save-revision-to=manifest_revision
-        --recipe-name=${BB_RECIPE_NAME}
-        --verbose
-  artifacts:
-    paths:
-      - manifest_revision
-
-
-#yamllint:
-#  extends: .yamllint
-
-# --------------------------------------------------------------------------------------
-# Stage: merge
-# --------------------------------------------------------------------------------------
-merge:
-  extends: .infrastructure
-  stage: merge
-  rules:
-    #- if: $CI_COMMIT_BRANCH == "$MASTER_BRANCH_PROJECT"
-     - if: $CI_PIPELINE_SOURCE == "push" && $CI_COMMIT_BRANCH == "main"
-       when: always
-  script:
-    - cd ${CI_PROJECT_DIR}
-    - echo ${CI_SERVER_URL}
-    - echo ${GITBOT_TOKEN}
-    - echo ${MANIFEST_PROJECT}
-    - echo ${MASTER_BRANCH_MANIFEST}
-    - echo ${CI_COMMIT_SOURCE}
-    - echo ${CI_MERGE_REQUEST_SOURCE_BRANCH_SHA}
-    - python3 scripts/merge_into_manifest.py
-        --gitlab-url=${CI_SERVER_URL}
-        --token=${GITBOT_TOKEN}
-        --manifest-project=${MANIFEST_PROJECT}
-        --master-branch=${MASTER_BRANCH_MANIFEST}
-        --project=${CI_PROJECT_PATH}
-        --master-branch-project=${MASTER_BRANCH_PROJECT}
-        --commit=${CI_COMMIT_SOURCE}
-        --save-revision-to=manifest_revision
-        --recipe-name=${BB_RECIPE_NAME}
-  artifacts:
-    paths:
-      - manifest_revision
- 
- # --------------------------------------------------------------------------------------
- # Stage: build
- # --------------------------------------------------------------------------------------
-build:
-  stage: build
-  tags:
-    - infrastructure
-  rules:
-    # Do not run build if the "skip build" label is set on the merge request
-    - if: $CI_MERGE_REQUEST_LABELS =~ /skip build/
-      when: never
-    # execute this in MR only and not for integrate/gitlab-ci/ integrations
-    # branches. These are build after the integration has been done in all
-    # projects
-    - if: $CI_MERGE_REQUEST_IID && $CI_COMMIT_REF_NAME !~ /^integrate\/gitlab-ci\/.*/
-  script:
-    - echo "Building"
-  #trigger:
-  #  project: !reference [variables, MANIFEST_PROJECT]
-  #  branch: "integrate/${CI_PROJECT_NAME}/${CI_COMMIT_REF_NAME}"
-  #  strategy: depend
-# 
-# --------------------------------------------------------------------------------------
-# Stage: check
-# --------------------------------------------------------------------------------------
-check:
-  extends: .infrastructure
-  stage: check
-  rules:
-    # Do not run check if the "skip build" label is set on the merge request
-    - if: $CI_MERGE_REQUEST_LABELS =~ /skip build/
-      when: never
-    # Do not integration pipeline for merge requests for integrate/gitlab-ci/ branches
-    # The integration is done from the pipeline in gitlab-ci already
-    - if: $CI_COMMIT_REF_NAME =~ /^integrate\/gitlab-ci\/.*/
-      when: never
-    - if: $CI_MERGE_REQUEST_IID
-    # Explicitly allow externally triggered pipelines in every case
-    - if: $CI_PIPELINE_SOURCE == "pipeline" || $CI_PIPELINE_SOURCE == "api"
-  needs: ["integrate"]
-  allow_failure: true
-  script:
-    - cd ${CI_PROJECT_DIR}
-    # When running in a trigger pipeline the CII_MERGE_REQUEST_IID is not set
-    # but CI_OPEN_MERGE_REQUESTS. We use  the first of this comma separated list
-    # in this case
-    - if [ -n "${CI_MERGE_REQUEST_IID}" ];then
-        MERGE_REQUEST="${CI_MERGE_REQUEST_IID}";
-      else
-        MERGE_REQUEST="${CI_OPEN_MERGE_REQUESTS%%,*}";
-      fi
-    # The 'parent_merge_request' is passed from the trigger
-    # in case this check job is part of a gitlab-ci integration
-    # pipeline. It is only used to display the correct MR to run again
-    # in a failed check
-    - if [ -n "${parent_merge_request}" ];then
-        PARENT_MR="--parent-merge-request=${parent_merge_request}";
-      fi
-    - python3 scripts/check_if_integration_branch_is_up_to_date.py
-        --gitlab-url=${CI_SERVER_URL}
-        --token=${GITBOT_TOKEN}
-        --manifest-project=${MANIFEST_PROJECT}
-        --integration-base=${MASTER_BRANCH_MANIFEST}
-        --project=${CI_PROJECT_PATH}
-        --merge-request=${MERGE_REQUEST}
-        --verbose
-        ${PARENT_MR}
diff --git a/testing.yml b/testing.yml
deleted file mode 100644
index 1eafbe4..0000000
--- a/testing.yml
+++ /dev/null
@@ -1,14 +0,0 @@
-stages:
-  - testing
-
-testing:
-  stage: testing
-  tags:
-    - infrastructure
-  timeout: 10m
-  image: secodocker/manifest-test:vtemp
-  tags: 
-    - if: $CI_PIPELINE_SOURCE == "schedule"
-      when: always
-  script:
-      - echo ${CI_PROJECT_ROOT_NAMESPACE}
-- 
GitLab