[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [RFC PATCH 0/6] Using GitLab CI for build testing
On 3/12/18 10:31 PM, Doug Goldstein wrote: > Really early work on switching over to using GitLab CI over > Travis CI. GitLab is a competitor to GitHub with some advantages > such as an integrated CI system with a lot more flexibility > and control. It additionally is fully open sourced unlike GitHub > and Travis CI. We can even run an instance if that is preferred > over using the hosted instance. > > This change uses GitLab CI's ability to use Docker based runners > for running tests. With GitHub we also use a Docker based runner > but we are limited to one Docker container that is then morphed > a number of different ways. With this approach we can specify > different Docker containers for every run (or use the same). By > using different Docker containers we can build environments that > match systems where Xen can and should build. Using this > approach we should be able to cutdown on the number of surpise > build failures encountered by users. > > An example run can be seen here: > https://gitlab.com/cardoe/xen/pipelines/18789907 > > If there is interest in this I will move it over to the "xen-project" > name space in the next version. Worth noting another advantage is that builders can be VMs or even physical hosts as well. So we can have a FreeBSD VM that can be a build environment. Further more the above link is to a GitLab pipeline, pipelines are made of stages which are further composed of jobs. Currently the example uses one stage called build and all the different distros are different jobs. But there's a lot of flexibility as to what can be done here. There can be stages that check code style or other pre-flight checks that people may be interested. There can be stages that happen after the build stage as well such as some simple tests (e.g. I use it to run the just built xen.gz with an initramfs only dom0 that contains a small Alpine Linux VM that spits out a string to an HTTP endpoint which decides that Xen build is good enough to allow it to be merged into our testing branch). Overall there are a lot more possibilities than what I've put together so far. -- Doug Goldstein Attachment:
signature.asc _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |