On Mon, Mar 12, 2018 at 11:29:47PM -0500, Doug Goldstein wrote:
> 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.

Mostly looks fine. And I think having this new dockerised build is good.
Please document what is needed to add ARM support. I suppose we just
need to install the cross-toolchain and write the right command in


Xen-devel mailing list

Reply via email to