Hello HAProxy developers,

At work we are going to use more and more ARM64 based servers and HAProxy
is one of the main products we rely on.
So I went checking whether HAProxy project has a CI environment for testing
on ARM architecture.
I've found this recent discussion:
https://www.mail-archive.com/haproxy@formilux.org/msg35302.html  (I didn't
find a way how to continue on the same mail thread, so I'm starting a new
one. Apologies for that!).
>From this discussion and from
https://github.com/haproxy/haproxy/blob/master/.travis.yml I understand
that there is no public CI in use (i.e. TravisCI or CirrusCI) but some of
the developers run some tests locally regularly.
I've forked the project and tested on TravisCI (
https://travis-ci.org/martin-g/haproxy/builds) but unfortunately the builds
were not very stable:
1) some tests fail sometimes. I guess it is because of some timing issues
For example:
- https://travis-ci.org/martin-g/haproxy/jobs/636745241
- https://travis-ci.org/martin-g/haproxy/jobs/636750676
- https://travis-ci.org/martin-g/haproxy/jobs/636763346
2) There was some weird issue on testing with LibreSSL
The output redirect at
https://github.com/haproxy/haproxy/blob/bb9da0b8e23c46caab34fe6005b66fa8065fe3ac/.travis.yml#L96
for
some reason got stuck the build. I've removed temporarily the output
redirects and then it passed. So, it looks like some issue with TravisCI
environment.

In addition I've run the build and tests on one of our machines and all was
OK!

My question to you is: Are you happy with your current way of testing ARM
architectures or you want to add more ?
Here are some options:
1) enable TravisCI
2) my company is willing to donate an ARM64 based VM, if you are interested.
You will have a SSH access and a user with sudo permissions to install
anything that is needed.
The spec is aarch64 8 cores CPU 2GHz (Kunpeng), 16GB RAM, 500G disk space
and 5M network bandwidth. The OS could be any of CentOS 7.4/7.5/7.6,
EulerOS 2.8, Fedora 29, OpenSuse 15.0 and Ubuntu 16.04/18.04.

In both cases it will be ARM64. From the earlier mail discussion I
understand you would prefer ARM32.

Kind regards,
Martin

Reply via email to