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

[Minios-devel] automation: Creating a patchwork instance to improve pre-commit build testing



Hi all,

Wei and Doug have recently been improving [xen.git] / automation / build, 
implementing some of the functionality outlined in [1] (see "CI / CD" heading). 

We are intending to take every patch series that is sent to xen-devel and 
create a branch at https://gitlab.com/xen-project/xen.git scoped to something 
like "ml/<msg-id>". ml stands for mailing list. The goal is to run whatever 
basic CI tests we can to help reviewers and contributors. Wei and Doug have 
gotten things to the point where we can compile against a number of distros and 
they continue to expand that functionality. 

What is missing, is the capability to take patch series from the mailing list 
and use the posted patches to trigger the CI/CD functionality. We are planning 
to use Patchwork because it provides functionality to allow us to do this via 
the Patchwork API (https://patchwork.readthedocs.io/en/latest/api/rest/) 
Originally Doug suggested he could just try this via one of his own VMs, but 
the recent introduction of the GDPR creates risks and obligations for everyone 
(both individuals and companies) who processes Xen Project related mailing list 
data (including git meta-data). To avoid this, we were planning to run 
patchwork on a new Xen Project hosted VM, for the sole purpose of using the 
Patchwork API. 

At this stage, we are not intending to expose the patchwork UI.

# How does this impact me?
The contribution workflow is *not* impacted by this change, but once up and 
running the following will happen once you post a patch or patch series to 
xen-devel:
* Patchwork will take patch series from the mailing list and applies it
* CI/DC testing is triggered
* A test report will be sent as a mail to the patch or the series (aka the 00 
patch of the series)

This does mean though that series which do not build or show other issues, will 
likely not be reviewed until the tests pass. This would lessen the burden on 
reviewers, as they will know whether the code submitted builds on a wide array 
of environments. 

# Supported build environments (for now)
For now, we are only supporting this on x86. The exact list of distros we build 
against can be found in [xen.git] / automation / build 
Arm support will be added later, once the missing pieces are in place (see [1] 
section "What OSs (architectures) should we support?") 

# What about checkpatch.pl?
Once clang-format changes have been completed, Wei and Doug are going to look 
at automating code style checks as well. Iurii Artemenko is working on 
clang-format improvements that will allow us to work around the issues outlined 
in [2]. There are still 3 missing pieces (see [3]). 

I don't think this is a controversial proposal, but I wanted to ask whether 
there are any objections or suggestions. I included the minios-devel list, as 
the Unikraft project is planning to introduce patchwork into their workflow.

Best Regards
Lars


# References
[1] https://lists.xenproject.org/archives/html/xen-devel/2018-07/msg00126.html ;

[2] https://xen.markmail.org/thread/pc2dhjgbgrdcz5sb
[3] Coding style patterns used in Xen that we cannot yet support

Braces should be omitted for blocks with a single statement. e.g.,
 if ( condition )
     single_statement();
 
Comments
--------
 
 Only C style /* ... */ comments are to be used.  C++ style // comments
 should not be used.  Multi-word comments should begin with a capital
 letter.  Comments containing a single sentence may end with a full
 stop; comments containing several sentences must have a full stop
 after each sentence.
 
 Multi-line comment blocks should start and end with comment markers on
 separate lines and each line should begin with a leading '*'.
 
 /*
  * Example, multi-line comment block.
  *
  * Note beginning and end markers on separate lines and leading '*'.
  */
 
Emacs local variables
---------------------
A comment block containing local variables for emacs is permitted at
the end of files.  It should be:
 
 /*
  * Local variables:
  * mode: C
  * c-file-style: "BSD"
  * c-basic-offset: 4
  * indent-tabs-mode: nil
  * End:
  */


_______________________________________________
Minios-devel mailing list
Minios-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/minios-devel

 


Rackspace

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