Continuous integration/Quibble/nan

Quibble is a Python script for setting up a MediaWiki instance and running various tests against it.

It works by cloning MediaWiki core and several extensions, installing dependencies, creating the database, and running one or more test commands.

Iân-sin ua̍t-to̍k

 * Introducing Quibble, Antoine Musso (April 2018), phabricator.wikimedia.org.

Tshòng-kiàn hām pòo-sū sin-ê Quibble pán-pún
This is moderately fiddly and stressful, and should be done when you have a fair amount of time free and CI is relatively quiet; Fridays are commonly picked.


 * 1) Create the new release tag (example):
 * 2) Run quibble's master branch locally to ensure that you're confident the basics work; this will be imperfect, but is a good start.
 * 3) Determine the new version number
 * 4) Update , replacing the placeholder section with a list of every commit since the previous release
 * 5) Create this update as a change, submit it to code review, and wait for it to be merged
 * 6) Once merged, tag the tip of the branch with   (updated with the appropriate version number) and the publish with.
 * 7) Update   to put in the next release's placeholder section.
 * 8) Create the images using the tag (example)
 * 9) In integration-config's   directory, manually edit the   for the primary quibble image or images to specify the new version (as of 2020-06-04, this is for   and  ).
 * 10) Use docker-pkg to create the appropriate cascade of   updates, e.g.
 * 11) Build the images locally to ensure they still build:
 * 12) Check the locally-built images to ensure that quibble correctly updated:   and then   and see that the correct version number is shown.
 * 13) Create this update as a change, submit it to code review, and wait for it to be merged.
 * 14) Create and publish the new images on the CI production server:   (remember to   this action in IRC) – 🐌 this will take a while, perhaps half an hour or more
 * 15) Switch CI jobs over to the new image (example)
 * 16) In integration-config's  directory, update the Jenkins job-builder YAML files to specify the new docker images:
 * 17) Verify that these jobs build correctly:
 * 18) Get a list of all jobs which will be updated by the change; there will be around 150 as of 2020-06-04.
 * 19) Push these updates as a commit to code review.
 * 20) Based on your knowledge of the changes in quibble, pick a likely simple, infrequent, fast-running job to manually change over, and push it:
 * 21) Manually trigger run a run of this job through the Jenkins Web interface, and carefully watch the output to ensure it works as it used to where it should, and in a different way where quibble's changes should change things.
 * 22) If you spot an error, rollback the job to the definition in master immediately rather than debugging live; remember that other people's workflows depend on CI continuing to work.
 * 23) Repeat this with increasingly major/high-profile jobs until you are satisfied that you or someone else on IRC would have noticed if the jobs were broken.
 * 24) Update the rest of the jobs in your list.
 * 25) Merge the commit as deployed.
 * 26) Continue to monitor CI for a while, in case things blow up despite your hard work. If it does, revert everything.

Guā-pōo liân-kiat

 * Documentation