Project

General

Profile

Actions

Feature #4727

open

Add more distro/platform/archs to jenkins CI

Added by pespin over 3 years ago. Updated 11 months ago.

Status:
Feedback
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
08/25/2020
Due date:
% Done:

60%

Spec Reference:

Description

Currently we rely on OBS to run unit test software on several architectures/distributions/versions. However, OBS hosts lack some features which means we need to disable them when we run there (such as socket_sctp_test), and hence only get tested mostly only in x86_64 on one debian version.

That means we don't test such features in ARM, or in Ubuntu or CentOS, or debian unstable.


Related issues

Is duplicate of Core testing infrastructure - Bug #4789: no gerrit verifications on a 32bit architectureClosedosmith10/09/2020

Actions
Actions #1

Updated by laforge over 3 years ago

  • Assignee set to laforge

I think we should run related tests as part of the 'master' tests, or as separate tests that run (at most) once per day. Exploding our configuration matrix for gerrit review is going to slow down our development process too much.

So I would say:
  • Add one i586 target to the gerrit job (or switch one of the existing targets from amd64 to i586)
  • execute "make distcheck" at least on one arm (e.g. our "Debian9-rpi4build) and on CentOS8/amd64

I'll start by looking at creating a few related build slaves.

Actions #2

Updated by laforge over 3 years ago

  • % Done changed from 0 to 10

One interestign problem just occurred: docker-ce doens't have any publicly available builds for 32bit x86.

N: Skipping acquire of configured file 'stable/binary-i386/Packages' as repository 'https://download.docker.com/linux/debian buster InRelease' doesn't support architecture 'i386'

So we cannot have a debian9/debian10 lxc in i386 which then runs all our docker based tests.

Somebody seemed to have an old patch to be able to build docker on i386: https://github.com/mforkel/docker-ce-i386 - but we don't really want to maintain our own docker builds, do we?

Actions #3

Updated by laforge over 3 years ago

  • Status changed from New to In Progress
  • % Done changed from 10 to 30

I switched to the debian-supplied docker.io package for now.

Next problem was that we don't have binary packages libfftranscode for anything but amd64.

There also were a variety of limitations in our ansible playbook, but I'm happy to report that I now have successfully deployed "setup-jenkins-slave.yml" on a Debian10 i586.

Actions #4

Updated by laforge over 3 years ago

  • % Done changed from 30 to 60

With https://gerrit.osmocom.org/c/docker-playground/+/21156 and https://gerrit.osmocom.org/c/docker-playground/+/21155 merged, I can actually run entire dockerized test suites on an i586 Debian10 lxc now, just like we can on amd64.

I know that's not exactly what this ticket is about, but I wanted to keep our amd64 and i586 setups as similar as possible.

Actions #5

Updated by laforge over 3 years ago

  • Status changed from In Progress to Stalled
Actions #6

Updated by laforge about 3 years ago

  • Assignee changed from laforge to osmith

assinging this to osmith, now that he's back to support us.

I think the ticket is still mostly about what I mentioned in comment number 3 above:

I think we should run related tests as part of the 'master' tests, or as separate tests that run (at most) once per day. Exploding our configuration matrix for gerrit review is going to slow down our development process too much.

  • Add one i586 target to the gerrit job (or switch one of the existing targets from amd64 to i586)
  • execute "make distcheck" at least on one arm (e.g. our "Debian9-rpi4build) and on CentOS8/amd64

Let me know if you need anything from me in terms of build slaves or the linke. I would hope we can build i586 docker containers and execute those on the existing amd64 lxc build slaves? And for ARM, we do have the Debian9-rpi4build.

Actions #7

Updated by osmith 11 months ago

  • Status changed from Stalled to Feedback
  • Assignee changed from osmith to laforge

What is the goal here, is it:

a) run the regression tests on different distros/architectures, after merging to master?

  • In that case, I would just add additional distros/architectures to osmocom:master on OBS, as this gets updated right after changes in master.
  • But TBH I'm not sure if it is worth it, as we would see the errors the next day when the packages fail to build in nightly. As it is extremely rare that this happens because of a distro/arch specific difference, IMHO it would be fine if we only see it the next day and the package is broken for a day/a few days in case of a weekend until it is fixed.

b) run the ttcn3 testsuites on different distros/architectures once a day?

  • we currently do this for debian 11 and centos 8 (and for pcap-client only, on centos7), all on x86_64
  • could add more distros / architectures here (but then again: do we even look at them? it seems we mostly/only look at -latest and master for debian 11 currently)
Actions #8

Updated by osmith 11 months ago

  • Is duplicate of Bug #4789: no gerrit verifications on a 32bit architecture added
Actions #9

Updated by pespin 11 months ago

From what I can read, the initial goal I wrote was to simply execute unit tests ("make check") in a representative handful of OS / archs.

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)