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

[1] https://docs.gitlab.com/ee/ci/yaml/#workflow



Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@huawei.com>

.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,34 @@ 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"
+    - if: '$CI_PIPELINE_SOURCE == "merge_request_event" && $CI_MERGE_REQUEST_TITLE =~ /^(wip|draft):.*/i'
+      when: manual
+      variables:
+        # See above for rationale.
+        CI_ONIRO_MANIFEST_URL: "$CI_MERGE_REQUEST_SOURCE_PROJECT_URL"
+        CI_ONIRO_MAGIC: ".gitlab-ci.yml:58: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: