[Patchew-devel] [RFC] Replacing tester with gitlab CI

[Paolo Bonzini]

On 01/10/20 13:02, Fam Zheng wrote:
> Here is an idea about how we can drop some code and simplify things.
> 
> Back when patchew tester was initially designed, there wasn't something
> as flexible as needed. Today, gitlab-ci has everything we want, so if
> the applier pushes tags to a gitlab repo, all the testing stuff can
> happen there.

Except one thing that we could keep on Patchew testers: gitlab-ci
doesn't have KVM (though we could use Travis or custom runners) which
QEMU needs in order to test FreeBSD.  But yeah I totally agree that
Gitlab or GitHub is a much better alternative to our custom testers.

Time for Patchew 3.0? :)

> Using gitlab-ci, we can change steps 3-6 to:
> 
> 3. The applier download mbox and applies as usual.
> 
> 4. The applier injects with `include:remote` a {.post: when:always}
> stage into .gitlab-ci.yml.
> 
> 5. The branch, with the modified .gitlab-ci.yml, is tagged and pushed
> to (for example)
> 
>     https://gitlab.com/patchew/ci-hub
> 
> 6. Gitlab CI kicks in and runs the tests.
> 
> 7. In the end, if any tests defined in the project's original .gitlab-
> ci.yml failed, the injected .post stage can report to patchew server
> with existing API, from there we can send notifications etc.

This could alternatively (and possibly more easily) be a Job webhook on
gitlab.com/patchew/ci-hub.

Paolo

> Benefits:
> 
> * Secrets and credentials can be managed securely with gitlab-ci env
> var.
> 
> * We let projects to define the tests, no more manual testing config at
> patchew server side.
> 
> * Less code for patchew.
> 
> * Gitlab provides free runner quota, and even managing gitlab-runners
> by ourselves is better than managing patchew testers ourselves because
> it's standard.
> 
> * Many things about gitlab CI UI are much better than patchew.org, so
> it's a great bonus - we can include a link to gitlab.com in the email
> report. Hopefully that is more familiar to people.
> 
> * This model is more scalable and hopefully easier to adopt by other
> projects, such as Xen and perhaps Linux too.
> 
> 
> Last but not least, we will need to PoC the injected .post stage.
> 
> Fam
>