Feature #4727
open
Add more distro/platform/archs to jenkins CI
Added by pespin over 3 years ago.
Updated 11 months ago.
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.
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.
- % 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?
- 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.
- % Done changed from 30 to 60
- Status changed from In Progress to Stalled
- 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.
- 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)
- Is duplicate of Bug #4789: no gerrit verifications on a 32bit architecture added
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.
Also available in: Atom
PDF