Page MenuHomePhabricator

Using Quibble with different backend than gerrit
Open, LowPublic

Description

Hello Hashar, thank you for your hard work on Quibble, awesome work.

We are planning on establishing local testing environment and really like quibble. Problem we have is that not all of our code is located on Gerrit, and we were thinking of a possiblity to have quibble work with another backend.

I can see that the URL for the repo is constructed of base URL [ 1 ] and ZUUL_PROJECT/EXT_DEPENDENCIES in [ 2 ]. We can define those in .env file.

We would also need to make [ 3 ] configurable in order to specify the mediawiki/core repository name.

We would very much appreciate your opinion on whether this is a worthwhile effort and a good idea or is quibble too specificly tied to gerrit.

Thank you

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript
hashar updated the task description. (Show Details)Feb 22 2019, 4:16 PM
greg removed hashar as the assignee of this task.Feb 22 2019, 4:34 PM
greg added a subscriber: hashar.

Indeed Quibble is hardcoded for Gerrit. Precisely, Quibble is a test runner intended for Wikimedia CI and for its Gerrit installation. It is also possible to use it locally, albeit the documentation is lacking and it is not that human friendly yet.

That being said, I am quite happy to see you have interest in Quibble. Seems it is rather straightforward to make adjustment in order to accommodate for other use cases. I guess you have fork of mediawiki on your own git hosting system with custom/private extensions hosted there as well.


The hardcoded base URL, can probably be made configurable with a new --git-base-url. For the context, that part of the code come from an utility named zuul-cloner which had the following usage:

zuul-cloner git_base_url project [project ...]

For Quibble I just hardcoded git_base_url=https://gerrit.wikimedia.org/r/p. So I guess we can just add a new option.

The parameter represent the canonical repository. It is used for the inital clone of the repositories, and if it already has been cloned, to refresh the repository and bring it up to date. The patchset itself is fetched from $ZUUL_URL which one would set to Gerrit in order to fetch an existing patch (by setting ZUUL_REF and ZUUL_BRANCH). CI craft commits on private git repositories and set ZUUL_URL to those, but I digress.


EXT_DEPENDENCIES is an artifact from some old CI jobs. I don't think it is actually needed, one can just pass the repositories to clone as arguments to Quibble. Eg:

quibble mediawiki/extensions/Example mediawiki/extensions/BoilerPlate

Eventually, I will drop EXT_DEPENDENCIES from Wikimedia CI and get remove it from Quibble as well in favor of passing the repositories as arguments.


mediawiki/core hardcoded because hmm.. Without mediawiki there is nothing we can do :-] mediawiki/skins/Vector is also always cloned since it is required to have a working web site (ie for Selenium browser tests).

As a hack, maybe you can create some alias using some url rewrite, but that is a bit of a hack. So here again, maybe we need yet another option to be added to Quibble.


Long term, I would like people to be able to list all the parameters in a config file and then invoke quibble using that file. Something like:quibble --profile=foobar.yaml with:

foobar.yaml
git_base_url: https://git.example.org/repos
projects:
 - mediawiki/extensions/Foobar
 - mediawiki/extensions/Example
db: sqlite
packages-source: composer

I also would like to decouple preparing the sources/install dependencies from running the tests. Solely running the tests is achievable by passing --skip-zuul --skip-deps but that is not very convenient. In that future model, you could craft your code layout using some custom script then invoke Quibble solely to run tests. It is still an idea floating around, no firm plans for implementation yet.

On Freenode you can reach #wikimedia-releng IRC channel in which some people are familiar with Quibble.

Hope that helps. If need be, we can arrange a video conf to elaborate further.

Side question: are you familiar with python? I am definitely willing to review patches proposals :-]

Thank you for your support and willingness to help.

yes, i have experience in python

I will get back to you once i have made some progress

Thank you again!!!

hashar triaged this task as Low priority.Apr 8 2019, 5:40 PM
Paladox added a subscriber: Paladox.Apr 8 2019, 5:44 PM