Test build with Travis CI #1044
Comments
|
Another option to consider is circleci - https://circleci.com/, which allows to use docker. In Seastar we switched from travis to circleci: scylladb/seastar@34b8eda. |
|
Hi, A couple of peers and I from the University of Texas at Austin are interested in contributing to OSv, and we thought a good place to start would be implementing some basic CI infrastructure (#1044). A couple of us have experience with CI/DevOps activities, so it shouldn't be too difficult. We have a few concerns though:
Discussion at: (https://groups.google.com/d/msg/osv-dev/dqca0wjU2Lo/qApxTAmFBQAJ) |
|
Ideally, we would want to make a new process repeatable. By that I mean we should have an ability to create test images/packages independently from running them. To achieve we might have 2 docker files - one to build and another one to run the tests. Also, the test results should be collected and published somewhere. To achieve this we could use capstan. The test packages could be uploaded to github release assets unless there is a better idea. Recently I have pushed the number of shell and python scripts aiming to help test a variety of workloads/apps on OSv. These also illustrate how capstan can be used above. Potentially we could reuse some of these scripts from build/run docker file. For more information about automated testing framework please read this. |
After this patch, subsequent commits to the osv GitHub Repo should trigger a build at https://travis-ci.org/cloudius-systems/osv. At the moment, the build consists of building the Ubuntu Docker image and building osv. This can easily be expanded upon by adding new entries to the .travis.yml. Addtionally, this could also be changed to not use the Docker image, if desired. Future expansion of this functionality is detailed here: https://github.com/cloudius-systems/osv/wiki/Automated-Testing-Framework The goal would be to build and test various apps, to ensure the change doesn't make any major regressions. Refs #1044 Signed-off-by: Mason Davis <mason.davis@utexas.edu> Message-Id: <20191203190247.507858-1-mason.davis@utexas.edu>
This patch sets up OSv travis CI pipeline to build and publish kernel as well as couple of capstan packages for every push to the main OSv repo. To make it possible, we use an open source project - ci-release-publisher - that provides python and shell scripts to automate building and publishing of build artifacts to github repo as part of Travis build chain. For more details please read https://github.com/nurupo/ci-release-publisher#ci-release-publisher. Please note that OSv setup follows "Publishing to a different repository" approach. In high-level everytime new commit is pushed to cloudius-systems/osv repo, travis would execute logic defined in .travis.yml that: - builds OSv docker builder image as defined in docker/Dockerfile.builder - runs OSv build in docker container to build kernel and unit tests - publishes kernel and unit tests in form or capstan mpm file into new repo - https://github.com/osvunikernel/osv-nightly-releases/releases. Eventually we might tweak the setup and publish artifacts once a day if there was a commit pushed. Note that .travis.yml delegates to the scripts defined in .travis/cirp that futher delegate to python scripts that are part of ci-release-publisher module. Lastly this patch adds useful python-based script github_releases_util.py aimed to help list daily releases and artifacts, push, downloads and delete artifacts. Completes #1044 Signed-off-by: Waldemar Kozaczuk <jwkozaczuk@gmail.com>
|
Completed with 7305d0f |
Travis-CI offers free CI (builds, tests, etc.) services to open-source projects. I opened an OSv page there:
https://travis-ci.org/cloudius-systems/osv
By adding a properly-formatted travis.yml project (see explanation in https://docs.travis-ci.com/user/tutorial/) we could easily ask Travis to automatically try to build OSv after every commit. Even more interestingly, we can ask it to build on several different Linux distributions, which can help us make sure that OSv still builds properly on older distros which the developers no longer have or test.
In the long run, it would be nice for these automated build to also do "make check" (i.e., run the tests), but these will be very slow because Travis doesn't support nested virtualization so everything will be run in qemu's emulator. But OSv's build itself should be quick it enough (it only minimally uses qemu to build the image - this will be slower than usual but probably not prohibitively slow).
The text was updated successfully, but these errors were encountered: