From 53242efe7991180a7e8524f07f0281f8e51daaa3 Mon Sep 17 00:00:00 2001
From: Zygmunt Krynicki <zygmunt.krynicki@huawei.com>
Date: Mon, 6 Jun 2022 11:39:46 +0200
Subject: [PATCH] .gitlab-ci.yml: define top-level workflow
It seems that defining rules with the "extends" mechanism is not working
very well. We may have better luck by using the workflow definition [1],
which incorporates our rules and automatically applies to all the jobs
in the pipeline.
Workflows cannot use "when: manual", so move that special-case to the
.workspace job instead.
[1] https://docs.gitlab.com/ee/ci/yaml/#workflow
Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@huawei.com>
---
.gitlab-ci.yml | 89 ++++++++++--------------------------
.oniro-ci/build-generic.yaml | 6 +++
2 files changed, 29 insertions(+), 66 deletions(-)
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 1bafcfc2..ef8f6459 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -27,52 +27,15 @@ include:
- local: '/.oniro-ci/test-generic.yaml'
- local: '/.oniro-ci/machines-and-flavours.yaml'
- local: '/.oniro-ci/dco.yaml'
- - template: 'Workflows/MergeRequest-Pipelines.gitlab-ci.yml'
-dco:
- extends: .dco
-
-build-docs:
- extends: .build-docs
-
-aggregate-docs:
- extends: .aggregate-docs
- needs: [build-docs]
-
-# Customize the .workspace job to set the path of the git repository to deviate
-# from what the git-repo prepares. This effectively allows testing incoming
-# changes that match the repository holding this CI pipeline.
-.workspace:
- variables:
- CI_ONIRO_GIT_REPO_PATH: oniro
-
-# Anchor job rules, which govern if a job is instantiated in a given pipeline.
-# This job is then used as another base to several different jobs, including
-# .bitbake-workspace, .build-rauc-bundle and the
-# .publish-rauc-bundle-to-hawkbit jobs.
-#
-# The rules are: modifications (changes) to the pipeline, meta-layers, flavours
-# and assets OR to placement of a tag on a commit OR when a job is scheduled.
-# In addition, draft merge requests will no longer start the heavy build jobs
-# automatically, giving an option to the developer, to start the desired jobs
-# manually.
-.workspace-rules:
- variables:
- CI_ONIRO_MAGIC: ".gitlab-ci.yml:61:.workspace-rules"
+workflow:
+ # Contains the essence of Workflows/MergeRequest-Pipelines.gitlab-ci.yml extended
+ # with Oniro specific logic.
rules:
+ - if: '$CI_COMMIT_TAG'
- if: '$CI_PIPELINE_SOURCE == "schedule"'
- variables:
- CI_ONIRO_MANIFEST_URL: "$CI_PROJECT_URL"
- CI_ONIRO_MANIFEST_BRANCH: "$CI_COMMIT_REF_NAME"
- CI_ONIRO_MAGIC: ".gitlab-ci.yml:67:.workspace-rules"
- - if: '$CI_PIPELINE_SOURCE == "merge_request_event" && $CI_MERGE_REQUEST_TITLE =~ /^(wip|draft):.*/i'
- when: manual
- variables:
- # See below for rationale.
- CI_ONIRO_MANIFEST_URL: "$CI_MERGE_REQUEST_SOURCE_PROJECT_URL"
- CI_ONIRO_MANIFEST_BRANCH: "$CI_COMMIT_REF_NAME"
- CI_ONIRO_MAGIC: ".gitlab-ci.yml:74:.workspace-rules"
- - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
+ - if: '$CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH'
+ - if: '$CI_MERGE_REQUEST_IID'
changes:
- assets/**/*
- flavours/**/*
@@ -86,34 +49,28 @@ aggregate-docs:
# is done here, so that it does not clobber scheduled pipelines.
variables:
CI_ONIRO_MANIFEST_URL: "$CI_MERGE_REQUEST_SOURCE_PROJECT_URL"
- CI_ONIRO_MANIFEST_BRANCH: "$CI_COMMIT_REF_NAME"
- CI_ONIRO_MAGIC: ".gitlab-ci.yml:90:.workspace-rules"
- - if: '$CI_COMMIT_TAG'
- # XXX: This needs CI_ONIRO_MANIFEST_BRANCH as well, most likely.
+ CI_ONIRO_MAGIC: ".gitlab-ci.yml:52:workflow"
+# Customize the .workspace job to set the path of the git repository to deviate
+# from what the git-repo prepares. This effectively allows testing incoming
+# changes that match the repository holding this CI pipeline.
+.workspace:
+ variables:
+ CI_ONIRO_GIT_REPO_PATH: oniro
+ CI_ONIRO_MANIFEST_URL: "$CI_PROJECT_URL"
+ CI_ONIRO_MANIFEST_BRANCH: "$CI_COMMIT_REF_NAME"
+ CI_ONIRO_MAGIC: ".gitlab-ci.yml:68:.workspace"
-# The three jobs defined below override the definitions from build-generic.yaml
-# to inject .workspace-rules and the rules defined therein. It is important to
-# understand that this is based on several separate systems: parsing and
-# loading yaml, processing the include rules, and processing extends rules.
-#
-# This specific trick (ab)uses the fact that yaml-top-level is one big map of
-# entities, and we can define an entity multiple times to effectively extend or
-# replace specific elements.
-#
-# The following three jobs are equivalent to copy-pasting the modified extends
-# line into the jobs in .oniro-ci/build-generic.yaml, because map/dictionary
-# entries compute the union of the defined keys, unlike list entries or scalars
-# that replace the previous value.
+dco:
+ extends: .dco
-.bitbake-workspace:
- extends: [.workspace-rules, .workspace]
+build-docs:
+ extends: .build-docs
-.build-rauc-bundle:
- extends: [.workspace-rules, .build-image]
+aggregate-docs:
+ extends: .aggregate-docs
+ needs: [build-docs]
-.publish-rauc-bundle-to-hawkbit:
- extends: [.workspace-rules]
# Build a RAUC update bundle for Raspberry Pi 4
bundle-raspberrypi4-64:
diff --git a/.oniro-ci/build-generic.yaml b/.oniro-ci/build-generic.yaml
index 7149b47f..0a03ca58 100644
--- a/.oniro-ci/build-generic.yaml
+++ b/.oniro-ci/build-generic.yaml
@@ -75,6 +75,12 @@
# Clean up after ourselves.
- rm -f "$CI_PROJECT_DIR"/.scratch-dir-name
- rm -rf "$SCRATCH_DIR"
+ rules:
+ - if: '$CI_PIPELINE_SOURCE == "merge_request_event" && $CI_MERGE_REQUEST_TITLE =~ /^(wip|draft):.*/i'
+ when: manual
+ variables:
+ CI_ONIRO_MANIFEST_URL: "$CI_MERGE_REQUEST_SOURCE_PROJECT_URL"
+ CI_ONIRO_MAGIC: ".oniro-ci/build-generic.yml:83:workflow"
# This job is documented in docs/ci/hidden-jobs/bitbake-workspace.rst
.bitbake-workspace:
--
GitLab