Here are the photos I took of the flipchart:
https://xenbits.xen.org/people/iwj/2019/summit-ci-branch-workshop/
My notes, in fairly unredacted form, are below. We should to write
this up into a proper proposal.
-8<-
Phase 1
A robot will create a Gitlab MR out of each of certain branches on
xenbits
Each such branch will be rebased onto staging and the result run
through the existing Gitlab CI tests.
After Gitlab CI has been run on each MR, if it passes, a robot pushes
it to staging.
After this has been running for a while, we ask maintainers to push
to the new robot input branches (above) rather than directly to
staging.
Phase 2
Instead of testing staging, osstest will directly combine number of
the outstanding gitlab MRs into a single candidate branch, and test
that. If it passes, it gets pushed to master.
If it fails, osstest uses the Gitlab API to write a comment to the MR
about this. Other metadata such as a request by a committer to retry
the branch, or priority information, can be handled the same way.
The selection of outstanding branches uses some kind of heuristic to
try to collect a combination which (a) bites of a good chunk of the
outstanding work and (b) is likely to pass.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
