[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] [Notes for xen summit 2018 design session ] Testing/Building with Docker/GitLab

The notes were taken by Florian Schmidt of NEC. Thank you

This has some actions on: Lars K, Xudong H, Doug G, Andrew C and Andrii A (who was not present)

We should certainly try and make progress on this as it has the potential to make life for code reviewers easier: it may be worth to organize a specific community call to keep the momentum up


## Testing/building with Docker/Gitlab


Problem: different environments (especially distros), leading to 

different gcc, binutil, qemu versions.

People report bugs that cannot be reproduced by the developers.

So maybe we should set up Docker containers for specific build environments.

There are also some Docker configs.

The containers themselves are on gitlab, not docker hub


### What OSs (architectures) should we support?

There is some discussion on whether we should support ARM (in addition 

of x86) for this system, since ARM Xen is typically cross-compiled from 

x86 anyway.

Stefano says that is true so far, but there is no need these days, and 

points to his ViryaOS talk tomorrow.

Virya isn't ready yet, but this is what it's going to bring to the table 

(late summer).

Many things in ViryaOS are not releveant here, but it has build 

environments inside containers.

There's some kind of overlap, and this could also be used for testing.

Stefano and Doug want to discuss this a bit more between them to see how 

their two systems compare.


Matt (ARM): we work on something very similar with a company called 


Infosifter hae experience with multi-architecture systems.

They build a multi-architecture build system, something like Travis.

Almost done (original plan: last week's dockercon)

The result would be a system that takes a dockerfile as input, and 

produces several output i seeral architectures.


### Action points:

Matt: provide information about the tool (see above) that is released 

soon, and heck how easily the current Dockerfile-based integration setup 

(see xen.git:automation/build/)) would work with their 

multi-architecture setup.

Doug: provide containerize script to the others to have a look how that 

could help



## CI/CD

Doug has a prototype of the  CI system running on gitlab.

He managed to get them to increase the free build minutes from 2000 per 

month to 20000, which then is enough for the project so far. However, 

the free-tier CI runners are slow because you get scheduled best-effort.

It would be helpful to have own gitlab CI runners on our own machines (VMs).

Lars tells Doug to write what is required and he'll talk to Ian to see 

what can be done there. (Should be possible.)


Stefano: what would be *really* useful is a CI integrated with the 

mailing list:

* take patch series from the mailing list

* apply to current HEAD

* do CI testing

* write report (with PASS/FAIL) as a mail reply to the 00 patch of the 



Intel has something like that for QEMU (called patchbot?). Maybe they 

can provide information about that to the xen mailing list, so we can 

add something like that?

This would also be much better than maintainer having to manually pick 

patches, push them to branches, and kick off CI runs.

One of the big advantages would be that it can save the reviewers a 

*lot* of time, because they can immediately see whether they even should 

review, or review other (working) patches.


### travis or not?


Travis is popular, well-known and stable, but it has some issues. Most 

importantly to us, you either need to use the google cloud or specific 

Dockerfiles (that you can extend with your own packages, but not do your 

own clean-slate Dockerfiles).

Matt mentions shippable, but the consensus is that this is effectively 

the same as the above gitlab integration.


### patchwork integration with patchbot?

If we have patchbot answering mails to the mailing list, it would be 

nice if patchwork can use those replies to automatically tag the patch 

series, for those who want to use patchwork.

Andrew points out that patchwork has ceaed functioning for the Xen 

mailing lists since some mail headers were changed recently.


### checkpatch.pl

Status: still not quite done (same as last year)


###Action Points:

Lars K.: talk to Matt and Dough to see whether we can get dedicated 

machines for the gitlab runners

Xudong H.: provide information about patchbot and how it could be used 

for Xen patch management

Doug G.: document how the CI works, so that people can set up their own 

gitlab-based CI, so that they can test their patches before they even 

hit the mailing list.

Andrew C.: find out how to fix patchwork

Andrii A.: please update on the status of checkpatch.pl. Maybe we need 

contributors to help out with getting this done


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.