diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml index 890d21a24042e4efa3e98864c49a39927bd8588e..775ce7e0fcefdacdafc6074e3d305c099d1719ba 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 158955d74c0571e8ceadb36006e1c7cf4d74f97e..a6378d685878b38ff9de99f601c524527ebd683a 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 04cb7ffb0caf96a34063b7def895d57faae08599..b35c9efcc473495e24c9ffb725f598fde7ef692c 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 c018c631bea2d5c148db97a31b005e23f37c2245..b7e7fcfb2cf2225a72d28d8e619b100f1152af05 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:  -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:  -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 587e05d0988b032b6d26fd718639021ea204ba54..6a4e2bf9e78ab514f71c85c20bfb477b35dfffca 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 27ceb66bc3195f4930dc0b18e67a5c117fbdc76d..7a81d80f40617d9b1089bb4e2c71a4e63703607d 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 0526b9b1adfc688e88de048a931427d35e991dc5..605a2c3a7df82ac28ad95e1c873d91fc13ab27fa 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 30cb495d45fd1327e93ef525877939c34c6b048e..34aabee23adf2128170dbb973572ec9a3ae536f8 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 8afd2a589cf76150e8c4365d4ba65a62df7b2111..0000000000000000000000000000000000000000 --- 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 012862686595e1ad8c146b16a267a1b67c8bbc4a..0000000000000000000000000000000000000000 --- 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 1eafbe4a0b3f3910655c0b0cf569d03669119cb3..0000000000000000000000000000000000000000 --- 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}