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

[Fam Zheng]

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.

Here is how it works now:

1. Patchew applier discovers new series that can be applied.

2. Patchew applier downloads mbox and applies the series on top of
"Based-on:", or mainline branch by default.

3. The applier will git-tag the applied series and push to a configured
mirror repo, such as https://github.com/patchew-project/qemu , and
record this repo/tag info in the patchew database.

4. The patchew tester polls for new git repo/tags from the patchew
server.

5. The tester clones the repo/tag and runs scripts sent from server.

6. The tester reports the result to the server.


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.

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