CI: Add initial AArch64 support

This only runs a single build job, to build without GL and not run any
tests, as KVM support is not yet included.

Signed-off-by: Daniel Stone <daniels@collabora.com>

.gitlab-ci.yml

@@ -104,6 +104,12 @@ check-commit:
     KERNEL_IMAGE: "bzImage"
     KERNEL_DEFCONFIG: "x86_64_defconfig"
 
+.debian-aarch64:
+  extends:
+    - .os-debian
+  variables:
+    BUILD_ARCH: "aarch64"
+
 # Build our base container image, which contains the core distribution, the
 # toolchain, and all our build dependencies. This will be reused in the build
 # stage.
@@ -115,6 +121,15 @@ x86_64-debian-container_prep:
   timeout: 30m
   stage: container_prep
 
+aarch64-debian-container_prep:
+  extends:
+    - .ci-rules
+    - .debian-aarch64
+    - .fdo.container-build@debian
+  tags:
+    - aarch64
+  timeout: 30m
+  stage: container_prep
 
 # Core templates for all of our build steps. These are reused by all build jobs
 # through the `extends` keyword.
@@ -186,6 +201,17 @@ x86_64-debian-container_prep:
     - job: x86_64-debian-container_prep
       artifacts: false
 
+.build-env-debian-aarch64:
+  tags:
+    - aarch64
+  extends:
+    - .debian-aarch64
+    - .fdo.suffixed-image@debian
+    - .build-env
+  needs:
+    - job: aarch64-debian-container_prep
+      artifacts: false
+
 .test-env-debian-x86_64:
   tags:
     - kvm
@@ -226,8 +252,7 @@ docs-build:
     - .build-no-test
 
 # Building without gl-renderer, to make sure this keeps working.
-x86_64-debian-no-gl-build:
-  extends: .test-env-debian-x86_64
+.build-options-no-gl:
   variables:
     MESON_OPTIONS: >
       -Dsimple-clients=damage,im,shm,touch,dmabuf-v4l
@@ -237,6 +262,17 @@ x86_64-debian-no-gl-build:
       -Dwerror=true
       -Dlauncher-libseat=true
   
+x86_64-debian-no-gl-build:
+  extends:
+    - .test-env-debian-x86_64
+    - .build-options-no-gl
+
+aarch64-debian-no-gl-build:
+  extends:
+    - .build-env-debian-aarch64
+    - .build-no-test
+    - .build-options-no-gl
+
 # Expose docs and coverage reports, so we can show users any changes to these
 # inside their merge requests, letting us check them before merge.
 #

.gitlab-ci/build-deps.sh

@@ -29,11 +29,32 @@ pip3 install sphinx_rtd_theme==0.4.3 --user
 # Build a Linux kernel for use in testing. We enable the VKMS module so we can
 # predictably test the DRM backend in the absence of real hardware. We lock the
 # version here so we see predictable results.
+#
+# To run this we use virtme, a QEMU wrapper: https://github.com/amluto/virtme
+# 
+# virtme makes our lives easier by abstracting handling of the console,
+# filesystem, etc, so we can pretend that the VM we execute in is actually
+# just a regular container.
+#
+# The reason why we are using a fork here is that it adds a patch to have the
+# --script-dir command line option. With that we can run scripts that are in a
+# certain folder when virtme starts, which is necessary in our use case.
+#
+# The upstream also has some commands that could help us to reach the same
+# results: --script-sh and --script-exec. Unfornutately they are not completely
+# implemented yet, so we had some trouble to use them and it was becoming
+# hackery.
+if [[ -n "${KERNEL_DEFCONFIG}" ]]; then
 	git clone --depth=1 --branch=drm-next-2020-06-11-1 https://anongit.freedesktop.org/git/drm/drm.git linux
 	cd linux
+
 	if [[ "${BUILD_ARCH}" = "x86-64" ]]; then
 		LINUX_ARCH=x86
+	else
+		echo "Invalid or missing \$BUILD_ARCH"
+		exit 1
 	fi
+
 	if [[ -z "${KERNEL_DEFCONFIG}" ]]; then
 		echo "Invalid or missing \$KERNEL_DEFCONFIG"
 		exit
@@ -42,6 +63,7 @@ if [[ -z "${KERNEL_IMAGE}" ]]; then
 		echo "Invalid or missing \$KERNEL_IMAGE"
 		exit
 	fi
+
 	make ARCH=${LINUX_ARCH} ${KERNEL_DEFCONFIG}
 	make ARCH=${LINUX_ARCH} kvmconfig
 	./scripts/config --enable CONFIG_DRM_VKMS
@@ -53,26 +75,12 @@ mv linux/arch/${LINUX_ARCH}/boot/${KERNEL_IMAGE} /weston-virtme/
 	mv linux/.config /weston-virtme/.config
 	rm -rf linux
 
-# Build virtme, a QEMU wrapper: https://github.com/amluto/virtme
-# 
-# virtme makes our lives easier by abstracting handling of the console,
-# filesystem, etc, so we can pretend that the VM we execute in is actually
-# just a regular container.
-#
-# The reason why we are using a fork here is that it adds a patch to have the
-# --script-dir command line option. With that we can run scripts that are in a
-# certain folder when virtme starts, which is necessary in our use case.
-#
-# The upstream also has some commands that could help us to reach the same
-# results: --script-sh and --script-exec. Unfornutately they are not completely
-# implemented yet, so we had some trouble to use them and it was becoming
-# hackery.
-#
 	git clone https://github.com/ezequielgarcia/virtme
 	cd virtme
 	git checkout -b snapshot 69e3cb83b3405edc99fcf9611f50012a4f210f78
 	./setup.py install
 	cd ..
+fi
 
 # Build and install Wayland; keep this version in sync with our dependency
 # in meson.build.