[GSoC] Draft Proposal for Multi-OS and Multiarch Continuous Tests Infrastructure
Philippe Ombredanne
pombredanne at nexb.com
Fri Mar 25 15:20:27 UTC 2016
On Fri, Mar 25, 2016 at 3:47 PM, Yulan Wei <weiyulanaheadlead at gmail.com> wrote:
> GSoC 2016 Proposal
>
> STUDENT NAME: Wei Yulan
> TITLE: Multi-OS and Multiarch Continuous Tests Infrastructure
> DATE: 25th Mar 16
>
> ABSTRACT
>
> For continuous testing strace in multi-os and multiarch, I propose to setup and configure an environment based on Travis CI or OpenSuse Build Service. We can run tests on various architectures and Linux distributions automatically on each commit and patch submission.
>
> SYNOPSIS
>
> The strace is a well-known diagnostic, debugging tool for Linux users, widely used in various architectures with various Linux distributions. To ensure the reliability of strace, it is necessary to run tests on different platforms to make sure it will work under all circumstances.
>
> Here are two solutions that I proposed.
>
> The first solution is to setup and configure a testing infrastructure based on Travis CI and qemu. Travis CI is a useful service that allows user to run continuous testing on it. I will emulate the different architecture by qemu, and make qemu images with testing environment for each linux distributions. Moreover, running test with different compilers is obviously more feasiable and easier to deploy than trying it under different architectures and linux distributions. Also, docker can be used in this project because it can provide convienence in deploying compilers in different testing environments.
>
> The second solution is OpenSuse Build Service. I noticed that the running time of Travis CI is not unlimited. OpenSuse Build Service is more flexible than Travis CI. OpenSuse Build Service provides a native multi-os and multiarch building environment, although it seems not easy to configure.(I had tried to run tests on OpenSuse Build Service, but it doesn’t work on some arch like armv6l.) Compared to other tools, the advantages of OpenSuse Build Service are when you submit your code, it will cross-compile your codes into executable file under all the architectures they supported. In this perspective, it will be convenient to use it to test strace on multi-os and multiarch.
>
> In order to find out the better solution, I will keep investigating Travis CI and OpenSuse Build Service by trying to build the continuous testing environment on both devices. If possible, I will also consider to combine the OpenSuse Build Service(it provides APIs) and Travis CI together, so that we can take advantage of both of them. As we know, strace is a project which is cooperated under git. Travis CI can detect the new commit, and run the tests automatically through Github Service Hook, but OpenSuse Build Service needs us to push the codebase manually every commits. We can submit codes to Travis CI and it will package them and send it to OpenSuse Build Service, thus, we can make use of advantages of both.
>
> Here are some links I referred.
>
> • https://www.tomaz.me/2013/12/02/running-travis-ci-tests-on-arm.html
> • https://hub.docker.com/r/multiarch/qemu-user-static/
> • https://hub.docker.com/r/multiarch/crossbuild/
> • https://build.opensuse.org/apidocs/
> • https://build.opensuse.org/package/show/home:aheadlead/strace#
>
> RELEVANT SKILLS
>
> I am Wei Yulan, a junior from China, majored in Computer Science at Nanjing University of Aeronautics and Astronautics.
>
> I have been a Linux user for 4 years, almost all the programming work I do is under UNIX-like systems with vi (Java is an exception). I have been writing C for 5 years since the high school. Also, I started to write Python after I entered university. The other relevant skills include linux system programming, shell programming and git.
>
> I had internship with Alibaba Inc last year, working in AliCloud Computing relative database service group. I built a Java VM performance monitor system for the internal distributed java cluster, aimed at discovering and tracking high frequency garbage collection, based on JStorm(an internal implementation of Storm), Grafana, InfluxDb, etc.
>
> I have built strace on my machine and understood how the test script works. I also have read the mailing lists about my project from last year until now.
>
> I have some open source projects following on github for your reference.
>
> • https://github.com/aheadlead/libcjstat (A header-only library for get statictics from running Hotspot Java VM written in C)
> • https://github.com/aheadlead/tinify-cli (A command-line client for tinyjpg.com written in Python, no english version readme at the moment)
>
> I knew GSoC and decided to participate in GSoC a few days ago when I saw the news. Honestly, I hardly had any time for preparation, and the plan for this idea is rough. The strace is the only one project in GSoC organization lists that I applied. I am very excited for this opportunity and I hope I can make contribution to it. In addition, I have enough to work on this project over the summer as I do not have any travel planned.
At this stage you should make your final submission to Google ASAP.
Thank you for the draft.
Have you checked out the qemu_multiarch_testing/ dir in the strace repo?
--
Cordially
Philippe Ombredanne
More information about the Strace-devel
mailing list