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

Re: [Xen-devel] Xen project CI systems and committer workflow



On Thu, 18 Apr 2019, Wei Liu wrote:
> Hi all
> 
> We now have Gitlab CI as a complementary system to Osstest and have planned to
> add bots. It's high time we think about how we integrate them and how it may
> improve our workflow.
> 
> ## Requirements
> 
> 1. We want to have light weight build tests before a patch series is reviewed
> or committed.
> 
> 2. We don't want to push broken patches to central repository such that
> everyone is blocked.
> 
> 3. We don't want to significantly change committer workflow.
> 
> Requirement 2 means that our current branching model will need to be changed.
> Details will follow.
> 
> ## Overview of automation systems
> 
> - Gitlab CI
> 
>     It is capable of running build tests with relatively short turnaround 
> time.
> 
> - Bots like Patchew and Patchwork
> 
>     They are able to slurp patches from xen-devel and maybe run customised
>     scripts on those patches.
> 
> - Osstest
> 
>     Pushgate, integration test system. It runs more sophisticated tests
>     compared to Gitlab CI. Turnaround time is long.
>     
> ## New world
> 
> There will be an unified endpoint for committers and bots. Committers and bots
> will have their git trees. Patches are committed to those trees. An automated
> system will get patches from those trees and trigger CI runs.
> 
> The system will pick up commits from one of the trees, merge them with master
> and send the merge to CI systems.
> 
> For bots, only Gitlab CI build tests will run. Results are sent back to
> xen-devel.
> 
> For committers' trees, at first Gitlab CI build tests are run, if the result 
> is
> successful, the merge commit is submitted to osstest. If osstest deems the
> merge is good, the merge is pushed (published) to xen.git, otherwise the merge
> is discarded. Test results are sent back to xen-devel.
> 
> With this system, all published commits should have already passed Gitlab CI
> and osstest tests.
> 
> ## Gaps
> 
> The component / system which merges trees and drives CI systems is missing.
> 
> Patchew and Patchwork don't do all the things we care about yet.

I understand the general principle and I am on board. But I missing some
details.

Is the idea that each committer would have his own git tree and branch
with a specific name which would be picked up automatically by the
CI-loop daily? In the style of linux-next? If it passed, it is given to
OSSTest automatically and eventually committed?

Or is it the idea that each committer would have a way to manually
submit a branch to the CI-loop for testing when he wished to do so?  In
the style of github pull-requests-based CI-loops? If this is the case,
then we just need a way to trigger the CI-loops on a given branch?

In any case, my only feedback would be to also allow CI-loops on
branches that are *not* meant to be committed automatically if tests
pass. So that we can apply a complex series to a branch and see if tests
pass before doing reviews or running experiments.

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

 


Rackspace

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