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:

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!!!

In T216819#4976377, @hashar wrote:

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:

Nice idea!

I see two focuses for development on this task,

• Gerrit and other backends can be decoupled further, one at a time. If anyone wants to whittle away at this or related, decoupling Gerrit or the webserver T225218: Consider httpd for quibble instead of php built-in server (mentioned because that's my own next favorite) would get support and code review.
• Implement your own source control backend however you manage to do it, in Quibble or even externally (followed by quibble --skip-zuul, for example). This work is useful even if it doesn't have the greatest abstractions, because we can generalize later using the experiences gained.

I'll mention as much in the task description.