Skip to contentSkip to conversation

of: Add a GitLab CI config file for unittests

RFC PATCH In review Rob Herring 2 participants 4 messages Nov 30, 2018 Device tree

lore
Share & tools
lore

Rob Herring

author maintainer
#0 lore raw

RFC PATCH 1/1 of: Add a GitLab CI config file for unittests

This adds a GitLab CI config file running the DT unittest in a usermode Linux build. The corresponding CI job can be found here:

https://gitlab.com/robherring/linux-dt-unittest/pipelines

This CI job can be duplicated by others by creating a kernel repo on a GitLab instance and configuring GitLab CI to use drivers/of/.gitlab-ci.yml config file.

Cc Frank Rowand <[email protected]>
Cc Daniel Vetter <[email protected]>
---
 drivers/of/.gitlab-ci.yml | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)
 create mode 100644 drivers/of/.gitlab-ci.yml
drivers/of/.gitlab-ci.yml new file +18 -0
new file mode 100644
index 000000000000..44a4824f5c33
@@ -0,0 +1,18 @@
+# SPDX-License-Identifier: GPL-2.0+
+
+image: registry.gitlab.com/robherring/docker-images/ubuntu-kernel-build
+
+variables:
+  ARCH: um
+
+job-unittest:
+  artifacts:
+    paths:
+      - "*.log"
+
+  script:
+    - echo -e "CONFIG_OF=y\nCONFIG_OF_UNITTEST=y\nCONFIG_OF_OVERLAY=y" > kernel/configs/extra.config
+    - make defconfig extra.config
+    - make -s -j $(nproc) vmlinux | tee build.log
+    - TMP=/tmp ./vmlinux > boot.log || true
+    - grep -E '\#\#\# dt-test \#\#\# end of unittest - [0-9]* passed, 0 failed' boot.log
Signature · 1 line
2.19.1
#1 lore raw
Quoted 6 lines · Rob Herring

This adds a GitLab CI config file running the DT unittest in a usermode Linux build. The corresponding CI job can be found here:

https://gitlab.com/robherring/linux-dt-unittest/pipelines

Quoted 7 lines

This CI job can be duplicated by others by creating a kernel repo on a GitLab instance and configuring GitLab CI to use drivers/of/.gitlab-ci.yml config file.

Cc Frank Rowand <[email protected]>
Cc Daniel Vetter <[email protected]>

Adding dri-devel.

Quoted 11 lines
---
 drivers/of/.gitlab-ci.yml | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)
 create mode 100644 drivers/of/.gitlab-ci.yml
drivers/of/.gitlab-ci.yml new file +0 -0
new file mode 100644
index 000000000000..44a4824f5c33

drivers/of/.gitlab-ci.yml line 3

Quoted 3 lines
drivers/of/.gitlab-ci.yml new file +3 -0
@@ -0,0 +1,18 @@
+# SPDX-License-Identifier: GPL-2.0+
+
+image: registry.gitlab.com/robherring/docker-images/ubuntu-kernel-build

I think it's better to include the docker recipe too. One because shipping pre-built dockers is a license nightmare, second because better hackability. For a full on example see:

https://gitlab.freedesktop.org/drm/igt-gpu-tools/blob/master/.gitlab-ci.yml

For the kernel I guess the question is where we should put all the docker files. There's going to be some need for subsystem specific tooling (e.g. we want something that has igt installed eventually for anything drm), so maybe just keeping them in subsystem directories is best. Was at least my plan with drivers/gpu.

Needs latest gitlab to make the build-on-demand stuff work, but gitlab.com has that.
-Daniel

Quoted 18 lines
drivers/of/.gitlab-ci.yml new file +15 -1
+
+variables:
+  ARCH: um
+
+job-unittest:
+  artifacts:
+    paths:
+      - "*.log"
+
+  script:
+    - echo -e "CONFIG_OF=y\nCONFIG_OF_UNITTEST=y\nCONFIG_OF_OVERLAY=y" > kernel/configs/extra.config
+    - make defconfig extra.config
+    - make -s -j $(nproc) vmlinux | tee build.log
+    - TMP=/tmp ./vmlinux > boot.log || true
+    - grep -E '\#\#\# dt-test \#\#\# end of unittest - [0-9]* passed, 0 failed' boot.log
--

2.19.1

Signature · 3 lines
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
author maintainer
#2 lore raw
Quoted 37 lines · Daniel Vetter
Quoted 6 lines · Rob Herring

This adds a GitLab CI config file running the DT unittest in a usermode Linux build. The corresponding CI job can be found here:

https://gitlab.com/robherring/linux-dt-unittest/pipelines

Quoted 7 lines

This CI job can be duplicated by others by creating a kernel repo on a GitLab instance and configuring GitLab CI to use drivers/of/.gitlab-ci.yml config file.

Cc Frank Rowand <[email protected]>
Cc Daniel Vetter <[email protected]>

Adding dri-devel.

Quoted 11 lines
---
 drivers/of/.gitlab-ci.yml | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)
 create mode 100644 drivers/of/.gitlab-ci.yml
drivers/of/.gitlab-ci.yml new file +0 -0
new file mode 100644
index 000000000000..44a4824f5c33

drivers/of/.gitlab-ci.yml line 3

Quoted 3 lines
drivers/of/.gitlab-ci.yml new file +3 -0
@@ -0,0 +1,18 @@
+# SPDX-License-Identifier: GPL-2.0+
+
+image: registry.gitlab.com/robherring/docker-images/ubuntu-kernel-build

I think it's better to include the docker recipe too. One because shipping pre-built dockers is a license nightmare, second because better hackability. For a full on example see:

Quoted 1 line

https://gitlab.freedesktop.org/drm/igt-gpu-tools/blob/master/.gitlab-ci.yml

Humm, but in the end you are still publishing the docker images either way. It's just a difference of publishing across projects and whether it's 2 jobs or 1 job with 2 stages.

I do tend to prefer the Travis-CI simplicity of just listing packages to install. It seems like the same could be done with docker and some magic on the server side. At least for the simple case of 'install this list of packages'.

Quoted 5 lines

For the kernel I guess the question is where we should put all the docker files. There's going to be some need for subsystem specific tooling (e.g. we want something that has igt installed eventually for anything drm), so maybe just keeping them in subsystem directories is best. Was at least my plan with drivers/gpu.

My plan (to the extent I have one) was to put the common parts into the docker image and leave the small job specific things in the job setup. Then I can use the same docker image across jobs. Maybe that's a pointless goal in the docker world.

My dockerfile is simple enough, I could probably just create it within the .gitlab-ci.yml.

Rob

#3 lore raw
Quoted 39 lines · Rob Herring
Quoted 37 lines · Daniel Vetter
Quoted 6 lines · Rob Herring

This adds a GitLab CI config file running the DT unittest in a usermode Linux build. The corresponding CI job can be found here:

https://gitlab.com/robherring/linux-dt-unittest/pipelines

Quoted 7 lines

This CI job can be duplicated by others by creating a kernel repo on a GitLab instance and configuring GitLab CI to use drivers/of/.gitlab-ci.yml config file.

Cc Frank Rowand <[email protected]>
Cc Daniel Vetter <[email protected]>

Adding dri-devel.

Quoted 11 lines
---
 drivers/of/.gitlab-ci.yml | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)
 create mode 100644 drivers/of/.gitlab-ci.yml
drivers/of/.gitlab-ci.yml new file +0 -0
new file mode 100644
index 000000000000..44a4824f5c33

drivers/of/.gitlab-ci.yml line 3

Quoted 3 lines
drivers/of/.gitlab-ci.yml new file +3 -0
@@ -0,0 +1,18 @@
+# SPDX-License-Identifier: GPL-2.0+
+
+image: registry.gitlab.com/robherring/docker-images/ubuntu-kernel-build

I think it's better to include the docker recipe too. One because shipping pre-built dockers is a license nightmare, second because better hackability. For a full on example see:

Quoted 5 lines
Quoted 1 line

https://gitlab.freedesktop.org/drm/igt-gpu-tools/blob/master/.gitlab-ci.yml

Humm, but in the end you are still publishing the docker images either way. It's just a difference of publishing across projects and whether it's 2 jobs or 1 job with 2 stages.

Yeah, but it comes with sources for rebuilding the image :-)

Quoted 4 lines

I do tend to prefer the Travis-CI simplicity of just listing packages to install. It seems like the same could be done with docker and some magic on the server side. At least for the simple case of 'install this list of packages'.

Yeah, gitlab is a bunch more explicit, and you need to do your caching of the setup you want yourself.

Quoted 10 lines
Quoted 5 lines

For the kernel I guess the question is where we should put all the docker files. There's going to be some need for subsystem specific tooling (e.g. we want something that has igt installed eventually for anything drm), so maybe just keeping them in subsystem directories is best. Was at least my plan with drivers/gpu.

My plan (to the extent I have one) was to put the common parts into the docker image and leave the small job specific things in the job setup. Then I can use the same docker image across jobs. Maybe that's a pointless goal in the docker world.

We do that too. The different docker images we have is for different testing (new/old distros, and the cross build chain in userspace conflicts, so need separate docker images for that). Aside from those cases where we need different images because they're incompatible, we do reuse them.

For the kernel there's much less of these userspace problems, so one image should be good enough for all jobs.
-Daniel

Quoted 4 lines

My dockerfile is simple enough, I could probably just create it within the .gitlab-ci.yml.

Rob

Signature · 7 lines
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dri-devel